On 5/15/24 10:09 AM, Achin Gupta wrote:
Hi Kamlesh,
Maybe a simpler way out would be to implement cooperative yielding semantics in the SCMI logic in EL3 such that:
We had also though about something like this, would require the addition of a some async versions of the standard SCMI calls. Or have the normal calls return some new return value like "retry" or "check back later" instead of pass/fail.
- SCMI SMC comes in from Normal world.
- SCMI command is sent to the SCP.
- EL3 SCMI logic starts a counter and polls for a response.
- When the counter hits 0, if the command has not completed and there
is a pending interrupt, complete the SMC to return to the Normal world.> 5. Normal world resumes the SMC. 6. Goto 3 unless the command has completed.
Yet another option would be to poll in the Normal world i.e. return immediately to Normal world after 2 above and then invoke an SMC repeatedly to check if the command has completed.
We would want to just return back to normal world immediately for anything other than the most simple calls for best RT performance. Otherwise we would need some policy on what the timeout would be, so that should be avoided.
Andrew
Just thinking aloud!
cheers, Achin
On Wed, 2024-05-15 at 13:48 +0000, Achin Gupta via TF-A wrote:
Hi Kamlesh and Francois,
Please find my comments inline...
On Wed, 2024-05-15 at 13:16 +0000, ff via TF-A wrote:
Le 15 mai 2024 à 14:42, Kamlesh Gurudasani via TF-A tf-a@lists.trustedfirmware.org a écrit :
Hi Achin,
Thanks for the suggestion,
Instead of adding the complexity of yielding semantics to BL31, have you considered migrating the SCMI operations to a S-EL0 partition that is managed by EL3 firmware? This would be a preemptible bare- metal partition and does not require migrating the SCMI operations to a TEE.
As per [0], we can't have a SEL1 firmware at all(e.g. OP-TEE), if we run S-EL0 partition image.
"It is not currently possible for BL31 to integrate SPM support and a Secure Payload Dispatcher (SPD) at the same time; they are mutually exclusive.
It has been possible to run a TEE and UEFI crypto as a separate partition for UEFI SecureBoot with U-Boot. Adding a second partition may be complex but not impossible.
I really don't think we would want to support this upstream but I will let the TF-A team comment. It makes EL3 solve a problem that should be solved in the TEE. This goes against keeping EL3 simple and opens the door for more vendor specific firmware to creep into EL3.
The best bet is to get the TEE to support FF-A and migrate the SCMI operations to an FF-A S-EL0 SP. The SP would work with any TEE that has a compliant FF-A implementation. On a >= v8.4 system, the same SP would work with Hafnium. It will require some upfront investment but is the most scalable approach in the long term.
cheers, Achin
I added Ilias in the to: as he knows alls the details
In the SPM bootflow, a Secure Partition image executing at S-EL0 replaces the Secure Payload image executing at S-EL1 (e.g. a Trusted OS). Both are referred to as BL32."
Let me know if you think otherwise.
What we want is,
- Run clock and power management services as well as TEE
services 2. We don't want to put clock and power and management services in TEE, so that we have liberty to use any TEE we want. Example, if we put our SCMI operations in OP-TEE, then we'll be constrained to use OP-TEE and only OP-TEE.
[0] https://trustedfirmware-a.readthedocs.io/en/latest/components/secur e-partition-manager-mm.html#secure-partition-manager-mm
Regards, Kamlesh
Achin Gupta Achin.Gupta@arm.com writes:
Hi Kamlesh,
We are aware that ARM v8.4-A onwards arch are having a SEL2 level with which we can run a vendor specific firmware
parallel to TEE at SEL1 in a secure partition. But how we do handle clock and power management for version which doesn't support SEL2?
Instead of adding the complexity of yielding semantics to BL31, have you considered migrating the SCMI operations to a S-EL0 partition that is managed by EL3 firmware? This would be a preemptible bare-metal partition and does not require migrating the SCMI operations to a TEE.
cheers, Achin
From: Kamlesh Gurudasani via TF-A tf-a@lists.trustedfirmware.org Sent: 15 May 2024 10:33 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Cc: bb@ti.com bb@ti.com; vigneshr@ti.com vigneshr@ti.com; d-gole@ti.com d-gole@ti.com; afd@ti.com afd@ti.com; hnagalla@ti.com hnagalla@ti.com Subject: [TF-A] Make TF-A (bl31) (El3 firmware) preemtible
Clock and power management in ATF, preemption issue.
I have seen that multiple Vendors are using arm scmi protocol to do clock management in bl31[0][1].
The problem with such implementations is any long running SCMI operations (like PLL locking for example) will hold the core in EL3 for extended period of time, adding to latency of NS EL1 interrupt handling as ATF is not preemptible.
This problem can be solved by making ATF preemptible, similar to how OP-TEE does it by by implementing a remote procedural call after it receives a interrupt. [2]How Linux does SMC call with YIELD flag enabled. [3]How OP-TEE handles the timer interrupt [4]How Linux receives an interrupt which came in EL3->SEL1
As quoted in exception Handling document in ATF docs[5]
"Receive exceptions, but handle part of the exception in EL3, and delegate processing of the error to dedicated software stack running at lower secure ELs (as above); additionally, the Normal world may also be required to participate in the handling, or be notified of such events (for example, as an event). In this scheme, exception handling potentially and maximally spans all ELs in both Secure and Normal worlds."
From this we can understand that we can delegate the exception to EL1 if we are already in EL3. (way to preempt)
We are aware that ARM v8.4-A onwards arch are having a SEL2 level with which we can run a vendor specific firmware parallel to TEE at SEL1 in a secure partition. But how we do handle clock and power management for version which doesn't support SEL2?
We don't want to put it in TEE as it will constraint our devices to that specific TEE.
I am starting to work on a proposal to make ATF preemptible similar to how OP-TEE is doing it. a)Will the similar approach from OP-TEE if implemented and working be accepted by ATF upstream? The SMC call with YIELD option will only be preemtible so will not affect the normal flow.
b)As quoted in Trusted Firmware-A Document[6] Page 94, "Yielding calls are reserved exclusively for Trusted OS providers" "Yielding 0- 1 Reserved for existing Armv7-A calls Yielding 2-63 Trusted OS Standard Calls"
Can this range be consumed within ATF/bl31 firmware or is it necessary to forward all yielding calls to Trusted OS?
[0] https://github.com/ARM-software/arm-trusted-firmware/blob/master/ plat/st/stm32mp1/stm32mp1_scmi.c [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21 840 [2] https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/opte e/smc_abi.c#L930 [3] https://github.com/OP-TEE/optee_os/blob/fc57019cb35c8c1bad66fc6d8 14ace5debde170a/core/arch/arm/kernel/thread_optee_smc_a64.S#L24 6 [4] https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/opte e/smc_abi.c#L842 [5] https://github.com/ARM-software/arm-trusted-firmware/blob/master/ docs/components/exception-handling.rst [6] https://trustedfirmware-a.readthedocs.io/_/downloads/en/latest/pd f/
Regards, Kamlesh -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org