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/stm... [1]https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 [2]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_abi.c... [3]https://github.com/OP-TEE/optee_os/blob/fc57019cb35c8c1bad66fc6d814ace5debde... [4]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_abi.c... [5]https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/compon... [6]https://trustedfirmware-a.readthedocs.io/_/downloads/en/latest/pdf/
Regards, Kamlesh -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org