Re: SMP enablement on Cortex-R52 (using PSCI ?)

From: Robin Murphy
Date: Wed Apr 19 2023 - 13:50:42 EST


On 19/04/2023 9:47 am, Sudeep Holla wrote:
Hi Ayan,

On Fri, Apr 14, 2023 at 12:24:38PM +0100, Ayan Kumar Halder wrote:
Hi PSCI developers,

We have a SoC where there are 4 Cortex-R52 which is distributed in two
clusters. So we have 2 Cortex-R52 in one cluster and 2 Cortex-R52 in another
cluster.

We wish to enable SMP on the 2 R52 within a cluster with Xen hypervisor (EL2
software) running on them.

We are trying to explore if we can use PSCI for booting the secondary cores.

Refer Cortex-R52 TRM
(https://developer.arm.com/documentation/100026/0101/?lang=en ), it
specifies the following :-

Page 24 - Section 1.4.1

"Support for Exception levels, EL0, EL1, and EL2."

Page 30 - Section 2.1.6

"The Cortex-R52 processor does not implement TrustZone® technology. It does
not support the ability to distinguish between secure and non-secure
physical memories."

Thus, there is no EL3 and secure world in Cortex-R52. It implements
AArch32-V8R architecture.


KVM hypervisor use PSCI to bring up secondaries in the VMs. So I am sure we
must be able to use the interface on Cortex-R52 without EL3.


Refer PSCI design document,
https://developer.arm.com/documentation/den0022/e/?lang=en

Page 18 -
"The PSCI specification focuses on the interface between Security states for
power management. It provides a method for issuing power management
requests. To deal with the requests, the PPF must include a PSCI
implementation. A PSCI implementation might require communication between
the PPF and a Trusted OS or SP."

Page 17 - Privileged Platform Firmware (PPF)

"For Armv7 systems, or Armv8 systems using AArch32 at EL3, PPF executes in
EL3."

From the above two statements, I infer that PSCI requires a PPF (running at
EL3) and a Trusted OS (running at secure EL2). If this is correct, then R52
cannot support PSCI. Please correct me if I am mistaken.

I wish to know how do we wake up the secondary core if PSCI is not
supported.


I will check with the authors if EL3 is a must for PSCI implementation, but
IMO it must not be though every aspects described in the spec may not apply
when used across EL2/EL1 boundaries especially when EL3 is not implemented
in the hardware.

Xen could provide PSCI to EL1 guests using the HVC conduit. However if EL2 is the highest implemented EL, then Xen is the most privileged software in the system - it would have to own the EL2 exception vectors, and it would have to own the low-level CPU bringup code. At that point it just wouldn't make much sense to HVC *itself* via the PSCI protocol when it could simply call the function directly.

Robin.