[PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver

[PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver

[Ayan Kumar Halder]

psci_init_0_2() stores the value returned by PSCI_VERSION in the global
psci_ver before checking that Xen supports it. When the firmware reports
a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI
version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value
and psci_cpu_on_nr stays 0.

psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver
on success. When the fallback fails as well (the /psci node is not
compatible with "arm,psci", it has no "cpu_on" property, or Xen boots
with ACPI), psci_init() returns an error that smp_init_cpus() ignores,
and psci_ver still holds the rejected version. All the users of
psci_ver then consider PSCI as available:
 - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method
   to bring up the secondary CPUs;
 - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the
   platform specific cpu_up() callback;
 - call_psci_cpu_off(), call_psci_system_off() and
   call_psci_system_reset() issue their PSCI calls.

As a result, Xen brings up each secondary CPU with an SMC using function
ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to
bring up CPU<n> (error -1)" for each secondary CPU.

Only set psci_ver once the version has been accepted, so that a rejected
version leaves psci_ver at 0 and Xen behaves as if PSCI was not
available. In the case above, Xen no longer issues any other PSCI call:
on arm64 the secondary CPUs using the "psci" enable-method are rejected
by smp_psci_init() and Xen boots on the boot CPU only; on arm32
platform_cpu_up() uses the platform cpu_up() callback, if any. CPU_OFF,
SYSTEM_OFF and SYSTEM_RESET are not issued either, as when the PSCI 0.1
fallback is used.

Fixes: 4d3d72c01467 ("xen/arm: Initial support for PSCI-0.2")
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
 xen/arch/arm/psci.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 634d0d7467..a720cf8d41 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -169,6 +169,7 @@ static int __init psci_init_0_2(void)
     };
     int ret;
     struct arm_smccc_res res;
+    uint32_t ver;
 
     if ( acpi_disabled )
     {
@@ -191,16 +192,17 @@ static int __init psci_init_0_2(void)
     }
 
     res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION);
-    psci_ver = PSCI_RET(res);
+    ver = PSCI_RET(res);
 
     /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
-    if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
+    if ( ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(ver) != 1 )
     {
         printk("Error: Unrecognized PSCI version %u.%u\n",
-               PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
+               PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver));
         return -EOPNOTSUPP;
     }
 
+    psci_ver = ver;
     psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
 
     return 0;
-- 
2.25.1

Re: [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver

[Orzel, Michal]

On 21-Oct-26 15:26, Ayan Kumar Halder wrote:
> psci_init_0_2() stores the value returned by PSCI_VERSION in the global
> psci_ver before checking that Xen supports it. When the firmware reports
> a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI
> version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value
> and psci_cpu_on_nr stays 0.
> 
> psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver
> on success. When the fallback fails as well (the /psci node is not
> compatible with "arm,psci", it has no "cpu_on" property, or Xen boots
> with ACPI), psci_init() returns an error that smp_init_cpus() ignores,
> and psci_ver still holds the rejected version. All the users of
> psci_ver then consider PSCI as available:
>  - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method
>    to bring up the secondary CPUs;
>  - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the
>    platform specific cpu_up() callback;
>  - call_psci_cpu_off(), call_psci_system_off() and
>    call_psci_system_reset() issue their PSCI calls.
> 
> As a result, Xen brings up each secondary CPU with an SMC using function
> ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to
> bring up CPU<n> (error -1)" for each secondary CPU.
> 
> Only set psci_ver once the version has been accepted, so that a rejected
> version leaves psci_ver at 0 and Xen behaves as if PSCI was not
> available. In the case above, Xen no longer issues any other PSCI call:
> on arm64 the secondary CPUs using the "psci" enable-method are rejected
> by smp_psci_init() and Xen boots on the boot CPU only; on arm32
> platform_cpu_up() uses the platform cpu_up() callback, if any. CPU_OFF,
> SYSTEM_OFF and SYSTEM_RESET are not issued either, as when the PSCI 0.1
> fallback is used.
> 
> Fixes: 4d3d72c01467 ("xen/arm: Initial support for PSCI-0.2")
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
> ---
>  xen/arch/arm/psci.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index 634d0d7467..a720cf8d41 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -169,6 +169,7 @@ static int __init psci_init_0_2(void)
>      };
>      int ret;
>      struct arm_smccc_res res;
> +    uint32_t ver;
>  
>      if ( acpi_disabled )
>      {
> @@ -191,16 +192,17 @@ static int __init psci_init_0_2(void)
>      }
>  
>      res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION);
> -    psci_ver = PSCI_RET(res);
> +    ver = PSCI_RET(res);
>  
>      /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
> -    if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
> +    if ( ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(ver) != 1 )
>      {
>          printk("Error: Unrecognized PSCI version %u.%u\n",
> -               PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
> +               PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver));
>          return -EOPNOTSUPP;
>      }
>  
> +    psci_ver = ver;
>      psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
>  
>      return 0;
The patch would be simpler if you just set psci_ver = 0 right before
returning -EOPNOTSUPP. No need for the new local variable then. If you agree, I
can change on commit. With that:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal

Re: [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver

[Halder, Ayan Kumar]

Hi Michal,

On 23/10/2026 07:42, Orzel, Michal wrote:
>
> On 21-Oct-26 15:26, Ayan Kumar Halder wrote:
>> psci_init_0_2() stores the value returned by PSCI_VERSION in the global
>> psci_ver before checking that Xen supports it. When the firmware reports
>> a version other than 0.2 or 1.x, the function prints "Unrecognized PSCI
>> version" and returns -EOPNOTSUPP, but psci_ver keeps the rejected value
>> and psci_cpu_on_nr stays 0.
>>
>> psci_init() then tries the PSCI 0.1 fallback, which overwrites psci_ver
>> on success. When the fallback fails as well (the /psci node is not
>> compatible with "arm,psci", it has no "cpu_on" property, or Xen boots
>> with ACPI), psci_init() returns an error that smp_init_cpus() ignores,
>> and psci_ver still holds the rejected version. All the users of
>> psci_ver then consider PSCI as available:
>>   - on arm64, smp_psci_init() installs call_psci_cpu_on() as the method
>>     to bring up the secondary CPUs;
>>   - on arm32, platform_cpu_up() calls call_psci_cpu_on() instead of the
>>     platform specific cpu_up() callback;
>>   - call_psci_cpu_off(), call_psci_system_off() and
>>     call_psci_system_reset() issue their PSCI calls.
>>
>> As a result, Xen brings up each secondary CPU with an SMC using function
>> ID 0. An SMCCC compliant firmware refuses it, and Xen reports "Failed to
>> bring up CPU<n> (error -1)" for each secondary CPU.
>>
>> Only set psci_ver once the version has been accepted, so that a rejected
>> version leaves psci_ver at 0 and Xen behaves as if PSCI was not
>> available. In the case above, Xen no longer issues any other PSCI call:
>> on arm64 the secondary CPUs using the "psci" enable-method are rejected
>> by smp_psci_init() and Xen boots on the boot CPU only; on arm32
>> platform_cpu_up() uses the platform cpu_up() callback, if any. CPU_OFF,
>> SYSTEM_OFF and SYSTEM_RESET are not issued either, as when the PSCI 0.1
>> fallback is used.
>>
>> Fixes: 4d3d72c01467 ("xen/arm: Initial support for PSCI-0.2")
>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
>> ---
>>   xen/arch/arm/psci.c | 8 +++++---
>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>> index 634d0d7467..a720cf8d41 100644
>> --- a/xen/arch/arm/psci.c
>> +++ b/xen/arch/arm/psci.c
>> @@ -169,6 +169,7 @@ static int __init psci_init_0_2(void)
>>       };
>>       int ret;
>>       struct arm_smccc_res res;
>> +    uint32_t ver;
>>   
>>       if ( acpi_disabled )
>>       {
>> @@ -191,16 +192,17 @@ static int __init psci_init_0_2(void)
>>       }
>>   
>>       res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION);
>> -    psci_ver = PSCI_RET(res);
>> +    ver = PSCI_RET(res);
>>   
>>       /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
>> -    if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
>> +    if ( ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(ver) != 1 )
>>       {
>>           printk("Error: Unrecognized PSCI version %u.%u\n",
>> -               PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
>> +               PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver));
>>           return -EOPNOTSUPP;
>>       }
>>   
>> +    psci_ver = ver;
>>       psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
>>   
>>       return 0;
> The patch would be simpler if you just set psci_ver = 0 right before
> returning -EOPNOTSUPP. No need for the new local variable then. If you agree, I
> can change on commit. With that:
yes I agree with that.
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>

Thanks.

- Ayan