2023-04-14 11:29:01

by Ayan Kumar Halder

[permalink] [raw]
Subject: SMP enablement on Cortex-R52 (using PSCI ?)

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.


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.

Kind regards,
Ayan




2023-04-18 12:16:01

by Vladimir Murzin

[permalink] [raw]
Subject: Re: SMP enablement on Cortex-R52 (using PSCI ?)

Hi,

On 4/14/23 12:24, 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.
>

snip

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

It looks to me you need to provide/use platform defined method. I see that
Xen provides struct platform_desc with smp_init and cpu_up callbacks...

Cheers
Vladimir

> Kind regards,
> Ayan
>
>
>

2023-04-19 08:54:47

by Sudeep Holla

[permalink] [raw]
Subject: Re: SMP enablement on Cortex-R52 (using PSCI ?)

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.

--
Regards,
Sudeep

2023-04-19 17:53:39

by Robin Murphy

[permalink] [raw]
Subject: Re: SMP enablement on Cortex-R52 (using PSCI ?)

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.

2023-04-20 09:52:12

by Sudeep Holla

[permalink] [raw]
Subject: Re: SMP enablement on Cortex-R52 (using PSCI ?)

On Wed, Apr 19, 2023 at 06:50:26PM +0100, Robin Murphy wrote:
> On 19/04/2023 9:47 am, Sudeep Holla wrote:
> >
> > 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.
>

Agreed, I was focussing to much just on EL2/EL1. I don't know details on how
power management responsibilities are split between Dom0 and hypervisor, but
I am more interested in understanding how cpuidle/suspend would be structured
with the direct function calls.

--
Regards,
Sudeep