Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ee7095b4-0bab-d98e-0f7e-633672458b50@arm.com>
Date:   Wed, 19 Apr 2023 18:50:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: SMP enablement on Cortex-R52 (using PSCI ?)
Content-Language: en-GB
To:     Sudeep Holla <sudeep.holla@arm.com>,
        Ayan Kumar Halder <ayankuma@amd.com>
Cc:     mark.rutland@arm.com, lpieralisi@kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        Vladimir Murzin <vladimir.murzin@arm.com>,
        Stefano Stabellini <sstabellini@kernel.org>
References: <1cb7d428-c047-1485-e39d-465806f6ef0b@amd.com>
 <20230419084756.3gypfyuuezjj7tyd@bogus>
From:   Robin Murphy <robin.murphy@arm.com>
In-Reply-To: <20230419084756.3gypfyuuezjj7tyd@bogus>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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.