Order SI_SUB_SMP before intrhooks when !EARLY_AP_STARTUP
AbandonedPublic
Actions

Authored by scottph on Oct 13 2020, 7:17 PM.

Details

Reviewers

jhb
andrew

Summary

Interrupts needed for config_intrhook might target a cpu that
isn't the boot cpu, so order AP startup earlier.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

scottph created this revision.Oct 13 2020, 7:17 PM

Herald added a subscriber: imp. · View Herald TranscriptOct 13 2020, 7:17 PM

This works for my case, but I'm not sure if this will be a problem for other platforms, or maybe for downstream codebases?

Hmmm, that's an interesting idea. I don't know if this will work on other architectures off the top of my head. You can still try x86 without EARLY_AP_STARTUP in theory. @mhorne can perhaps try this on RISC-V?

In D26765#596859, @jhb wrote:

Hmmm, that's an interesting idea. I don't know if this will work on other architectures off the top of my head. You can still try x86 without EARLY_AP_STARTUP in theory. @mhorne can perhaps try this on RISC-V?

This boots okay on RISC-V, where I have tested EARLY_AP_STARTUP in the past. It seems like most SYSINITs in this range should be safe to be moved after SI_SUB_SMP, but a quick search for EARLY_AP_STARTUP shows a couple cases that should be adjusted:
sys/dev/hyperv/vmbus/vmbus.c - registers an intrhook conditional on !EARLY_AP_STARTUP
sys/dev/hwpmc/hwpmc_mod.c - registers SYSINIT to SI_SUB_SYSCALLS conditional on !EARLY_AP_STARTUP

@scottph I'd suggest searching through such cases yourself, since I only did so quickly.

D28340's approach of letting all CPUs get targeted by an ITS removes the need for moving around SI_SUB_SMP.

scottph abandoned this revision.Feb 17 2021, 10:11 PM