All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver
Date: Wed, 21 Oct 2026 14:26:40 +0100	[thread overview]
Message-ID: <20261021132640.599126-1-ayan.kumar.halder@amd.com> (raw)

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



             reply	other threads:[~2026-10-21 13:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 13:26 Ayan Kumar Halder [this message]
2026-10-23  6:42 ` [PATCH] xen/arm: psci: Do not keep a rejected PSCI version in psci_ver Orzel, Michal
2026-10-23 17:26   ` Halder, Ayan Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261021132640.599126-1-ayan.kumar.halder@amd.com \
    --to=ayan.kumar.halder@amd.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.