When bringing up a secondary CPU, call_psci_cpu_on() returns the PSCI
result codes back to arch_cpu_up(). If the physical CPU is already powered
on (PSCI_ALREADY_ON) or is powering on (PSCI_ON_PENDING), these negative
codes are treated as fatal errors. This causes Xen to fail the CPU bring-up.

Map PSCI_ALREADY_ON and PSCI_ON_PENDING return codes to PSCI_SUCCESS
inside call_psci_cpu_on(). This allows arch_cpu_up() to succeed and
lets __cpu_up() proceed to poll until the CPU is fully active.

References: Arm Power State Coordination Interface (DEN0022) Section 5.6.2
"Caller responsibilities", Section 6.6 "Implementation CPU_ON/CPU_OFF races".

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
---
Test CI pipeline: https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2609141554
---
 xen/arch/arm/psci.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index b6860a7760..6015bc0a5a 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -40,11 +40,16 @@ static uint32_t psci_cpu_on_nr;
 int call_psci_cpu_on(int cpu)
 {
     struct arm_smccc_res res;
+    int32_t ret;
 
     arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_secondary),
                   &res);
 
-    return PSCI_RET(res);
+    ret = PSCI_RET(res);
+    if ( ret == PSCI_ALREADY_ON || ret == PSCI_ON_PENDING )
+        return PSCI_SUCCESS;
+
+    return ret;
 }
 
 void call_psci_cpu_off(void)
-- 
2.43.0

Hi Dmytro,

On 20/06/2026 12:38, Dmytro Prokopchuk1 wrote:
> When bringing up a secondary CPU, call_psci_cpu_on() returns the PSCI
> result codes back to arch_cpu_up(). If the physical CPU is already powered
> on (PSCI_ALREADY_ON) or is powering on (PSCI_ON_PENDING), these negative
> codes are treated as fatal errors. This causes Xen to fail the CPU bring-up.

 From my understanding of PSCI CPU_ON, if either ON_PENDING or 
ALREADY_ON is returned then it means the parameters we passed for the 
secondary CPU will not be taken into account.

So always returning PSCI_SUCCESS for the two errors feels wrong. For 
instance, I would expect that the first call to PSCI CPU_ON for a given 
CPU is not meant to return ALREADY_ON/ON_PENDING. It might be fine for 
follow-up call, but such decision should be taken by the function that 
call PSCI CPU_ON multiple time on the same CPU.

I had a brief look at the call stack and I wasn't able to find any loop. 
Can you point me to one?

Cheers,

-- 
Julien Grall