Re: [PATCH v2] arm64: Disallow disabling boot CPU based on config

[Sudeep Holla <sudeep.holla@kernel.org>]

On Tue, Jul 21, 2026 at 02:58:49PM +0530, Sneh Mankad wrote:
> 
> 
> On 06-Jul-26 2:46 PM, Sudeep Holla wrote:
> > On Sat, Jul 04, 2026 at 08:43:39AM +0200, Daniel Lezcano wrote:
> >>
> >> Hi Sudeep,
> >>
> >> Le 03/07/2026 à 17:51, Sudeep Holla a écrit :
> >>> (It is always good to cc all PSCI maintainer for any ARM64 CPU
> >>> hotpug/suspend related changes)
> >>>
> >>> On Fri, Jul 03, 2026 at 04:50:02PM +0530, Sneh Mankad wrote:
> >>>> The Qualcomm SoCs like LeMans, Monaco support suspend to ram which leads
> >>>> the SoC to ACPI S3 similar state where SoC is turned off and DDR is
> >>>> retained. The hardware design on these SoCs forces a constraint to suspend
> >>>> and resume the system on boot CPU / CPU0.
> >>>>
> >>> And you fail to explain why they have that constraint.
> >>>
> > 
> > I still need the above to understand the issue/constraint better.
> 
> Above mentioned SoCs have boot CPU fixed to CPU0 in HW, whenever SoC boots
> up/cold boots it starts with CPU0.
> 
> These SoCs support suspend to ram which leads to ACPI S3 similar state
> (where SoC is turned off and DDR is retained).
> PSCI SYSTEM_SUSPEND typically will be executed on boot core itself unless it
> is already offlined and non boot CPUs gets offlined using PSCI CPU_OFF.
> 
> As HW constraint always makes the SoC to boot with boot CPU, consider a
> scenario, where
> 
> Boot CPU is already disabled / offline => suspend to ram is triggered => SoC
> enters ACPI S3 similar state (only DDR is retained and rest of the SoC is
> off).
> <So far good>

Not really, see below ...

> 
> External wake up arrives (say power key press) => SoC starts booting with
> CPU0 => CPU0 becomes first one to "land" in kernel now.
> 

Ideally the firmware could have handled it by booting/waking the suspended
CPU and turning itself off even if it is some h/w limitation to ensure
the firmware is PSCI spec compliant.

> Kernel may later bring up other non-boot CPUs via PSCI CPU_ON calls.
> However Kernel had already marked CPU0 as disabled/ offline but same ended
> up in kernel without PSCI CPU_ON call.
> 

... You resumed back on a wrong CPU.


> To prevent this inconsistent state, before starting suspend to ram, need to
> make sure CPU0 is always online from kernel/ disable offlining of the boot CPU.
> 

At least not in the way this patch does. Kconfig is not an option. Why is
the firmware not handling it properly ? Just resuming random CPU into the
kernel is firmware bug which either needs to be handled as f/w errata
or good if the firmware can be fixed.

> Although the HW constraint needs boot CPU to be online only when suspend to
> ram is triggered, current patch disallows disabling it for simplicity.
> 

That's very strange, so it sounds like not a real h/w constrain to make CPU0
as non-hotpluggable. PSCI CPU_SUSPEND resume path must handle wake up on
wrong CPU correctly and land/resume on the correct CPU in the kernel.

> > 
> >>> Is it because some secure context is not allowed to migrate ?
> >>>
> >>> We already have a mechanism for that in place and this hack is not at all
> >>> required.
> >> Do you mean a mechanism for the secure context or for preventing CPU0 ?
> >>
> > 
> > I meant constraint based on secure context.
> > 
> 
> This is not because secure context not allowed to migrate but above
> mentioned HW constraints.
> 

Sure not secure context related but a HW constraint that secure/PSCI
firmware ignored to handle correctly.

Fix the firmware or explore ways to handle it as FW errata.

-- 
Regards,
Sudeep