Re: [PATCH RFC v1 1/8] cpu/hotplug: Allow architecture-specific primary CPU bringup
From: Chang S. Bae
Date: Wed Sep 30 2026 - 00:45:09 EST
On 9/29/2026 5:20 PM, Borislav Petkov wrote:
On Sat, Sep 12, 2026 at 12:08:07AM +0000, Chang S. Bae wrote:
Parallel CPU bringup currently proceeds in two phases: first for the SMT
primary threads and then second for the remaining secondary threads. This
ordering avoids race conditions, specifically for x86 microcode loading.
Upcoming x86 changes expand the microcode loading scope beyond a single
core to package scope or even system-wide updates. Introduce architecture
hooks that allow customizing which CPUs participate in the first phase:
* arch_cpuhp_primary_aware() - indicates whether the architecture
provides a custom primary CPU selection scheme, or not.
* arch_cpuhp_get_primary_cpus() - returns a CPU mask for the first
bringup iteration.
Why are there two?
This pair is after the existing cpuhp_smt_aware() and cpuhp_get_primary_thread_mask() pair in kernel/cpu.c
I think cpu_primary_thread_mask alone isn't that obvious to indicate SMT on or off. So similarly arch_cpuhp_primary_aware() provides an explicit indication for the if statement.
Why are there even accessors at all when you can simply use
cpu_primary_thread_mask whereever you need it and drop all that gunk here and
in the next patch?
The series directs the bringup code to select different masks depending on the uniform scope reported by CPUID. That's very x86-ish code thus in arch/x86. So I ended up with accessors connecting to that x86 part.
But in a bigger picture, this is a part of the early loading support along with patch2/3/7. Introducing cpu_primary_core_mask itself in patch3 may be seen an overkill, TBH. In fact, the latency impact on early loading (when without uniform support) wasn't observed that much in practice. But, OTOH, one may also argue the loading scope should be consistent on both ends. So I think it is worth settling down on which approach to go.
Thanks,
Chang