Order SI_SUB_SMP before intrhooks when !EARLY_AP_STARTUP

[scottph]

Summary

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

Sponsored by: Ampere Computing

[scottph]

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

[jhb]

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?

[mhorne]

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.

[scottph]

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