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

["Orzel, Michal" <michal.orzel@xxxxxxx>]

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@xxxxxxx>
> ---
>  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@xxxxxxx>

~Michal