sparc64 EARLY_AP_STARTUP

[kbowling]

Summary

Enable EARLY_AP_STARTUP on sparc64

Test Plan

Boots on my v215, iflib igb msi-x comes up compiled statically into the kernel (note that requires other changes, so you'll need another msi-x device to duplicate your own tests)

[kbowling]

To clarify for @sbruno this isn't related to iflib or the issues we had there, just doing a thing while I'm in sparc64.

[marius]

FYI, this will require thorough review and testing to also do the right thing on machines where the per-CPU
time counters are used for time counting (which repeatedly was a source of problems during startup in the
past). You likely won't hit that case with a v215 unless you hack up fire(4) to use a lower quality for the
performance counter based time counter. Better, yet, would be testing with a machine that has more than
just 2 CPUs, e. g. with a v440, though. However, EARLY_AP_STARTUP still was preventing one of my x86-based
machines from booting, so my intent was to wait until the general bugs have been weeded out before looking
into adapting sparc64.

[jhb]

Marius, I'm not aware of any current issues on x86 with early startup. Can you please mail me details about your system that doesn't boot?

sys/sparc64/sparc64/mp_machdep.c

477

You need to be calling cpu_initclocks_ap() somewhere else then.

On x86 cpu_initclocks() changed to call cpu_initclocks_ap() when it was invoked instead of only initializating the BSP. You probably need the same change at the bottom of cpu_initclocks() in tick.c.

Also, you want to audit any uses of SI_SUB_SMP in the MD code as well as uses of 'cold' (not all 'code' changes need changing, but they probably need to be looked at to see if any changes are needed)

[sbruno]

Hrm ... this patch seems like abandon ware to me. Is it still relevant?

[kbowling]

Yeah we need to remove sparc64 from the tree before 12.0