[PATCH v3 00/12] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs

[Jinjie Ruan]

On 7/7/2026 1:39 AM, Will Deacon wrote:
> Hi Jinjie,
> 
> On Thu, Jun 25, 2026 at 09:34:36AM +0800, Jinjie Ruan wrote:
>> On 6/24/2026 8:16 PM, Will Deacon wrote:
>>> Please just give me the time I asked for. If you want to help out in the
>>> meantime, there are plenty of patches that need reviewing...
>>
>> It was a mistake on my part, and I sincerely apologize for wasting
>> community review resources and disrupting your schedule.
>>
>> I will absolutely back off now and wait for your official series. Lesson
>> learned. Thanks for your patience and for calling me out on this.
> 
> So I've mostly got the old series back on its feet:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=cpu-hotplug

Hi Will,

I tested the above-mentioned latest patch on v7.2-rc1 with error inject
on QEMU, which constructed the following errors:

1、CPU4 does not support 52-bit VA

2、CPU6 does not support 4K granule

3、CPU16 and CPU17 call cpu_die_early() early in check_early_cpu_features().

4、CPU18 call cpu_panic_kernel() early in check_early_cpu_features().

The error output is not correct especially for CPU4, CPU6, and CPU18 as
below, it seems that some error messages are overlapping on the same
CPU, and some errors are causing the CPU to be misidentified.:

(This leaves another blind spot where the 'failed to report alive state'
message is skipped for CPU16 and CPU17, as pointed out in
https://lore.kernel.org/all/bddf7a68-7789-4ec2-819c-aaaee8173c70@huawei.com/):

[    0.594323] CPU16: will not boot
[    0.605818] CPU17: will not boot

...

[   11.052387] CPU4 failed to report alive state
[   11.059799] Parallel CPU bringup failed; consider passing
"cpuhp.parallel=off" for a more accurate diagnosis.
[   11.060179] CPU4 detected lack of support for 52-bit VAs
[   11.060426] CPU4 detected lack of support for 4K granules

[   11.061103] Kernel panic - not syncing: CPU4 detected unsupported
configuration
[   11.061534] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
7.2.0-rc1-00019-g52296829d92b #305 PREEMPT
[   11.062052] Hardware name: linux,dummy-virt (DT)
[   11.062230] Call trace:
[   11.062339]  show_stack+0x18/0x24 (C)
[   11.062528]  dump_stack_lvl+0x11c/0x168
[   11.062684]  dump_stack+0x18/0x24
[   11.062818]  vpanic+0x568/0x574
[   11.062947]  do_panic_on_target_cpu+0x0/0x1c
[   11.063111]  secondary_start_kernel+0x0/0x188
[   11.063276]  cpuhp_bringup_ap+0x244/0x254
[   11.063430]  cpuhp_invoke_callback+0x168/0x2ac
[   11.063594]  __cpuhp_invoke_callback_range+0x90/0x118
[   11.063776]  _cpu_up+0xec/0x1b8
[   11.063905]  cpu_up+0xcc/0x158
[   11.064032]  cpuhp_bringup_mask+0x9c/0xe0
[   11.064189]  bringup_nonboot_cpus+0x12c/0x14c
[   11.064352]  smp_init+0x30/0x8c
[   11.064481]  kernel_init_freeable+0x18c/0x40c
[   11.064645]  kernel_init+0x24/0x1dc
[   11.064785]  ret_from_fork+0x10/0x20
[   11.066612] SMP: stopping secondary CPUs
[   11.068198] ---[ end Kernel panic - not syncing: CPU4 detected
unsupported configuration ]---

The expected output is as below:

        CPU4 failed to report alive state
        CPU4: is stuck in kernel
        CPU4: does not support 52-bit VAs

        CPU6 failed to report alive state
        CPU6: is stuck in kernel
        CPU6: does not support 4K granule

        GICv3: CPU8: found redistributor 8 region 0:0x00000000081a0000
        GICv3: CPU8: using allocated LPI pending table @0x0000000100360000
        CPU8: Booted secondary processor 0x0000000008 [0x410fd034]
        ...
        CPU16 failed to report alive state
        psci: CPU16 killed (polled 0 ms)
        CPU16: died during early boot

        CPU17: will not boot
        CPU17 failed to report alive state
        psci: CPU17 killed (polled 0 ms)
        CPU17: died during early boot

        CPU18 failed to report alive state
        Kernel panic - not syncing: CPU18 detected unsupported configuration

Best regards,
Jinjie

> 
> but there are still two issues left to resolve:
> 
>   1. The printing that can happen before RCU has started. Although I've
>      reduced this somewhat, there are still error paths in e.g.
>      verify_local_cpu_capabilities() that print a message before dying.
> 
>   2. check_local_cpu_capabilities() can mutate the system capability
>      state via update_cpu_capabilities(), so it's really dodgy running
>      that prior to synchronisation.
> 
> Since you've added patches in this series that try to tackle these
> problems, I'll reply on those two so we can figure out how we would like
> to proceed.
> 
> Cheers,
> 
> Will