Wed, Jun 22
Hi Okash,
Olivier is on holiday and once he is back next week, we can arrange something to discuss.
Mon, Jun 20
Thanks. It seems like we are converging. Would it make sense to set up a meeting to thrash out details? Any time this week will be preferable. Let me know what works for you. Arve and Peter are in Pacific time zone. Rest of us are based in UK I guess?
Mon, Jun 13
That is not what I meant. The NS SVE/FP access trap is needed to avoid saving and restoring the state when the SVE/FP registers are actively used by the secure world.
Fri, Jun 10
That is not what I meant. The NS SVE/FP access trap is needed to avoid saving and restoring the state when the SVE/FP registers are actively used by the secure world, but not by the normal world. In the sequence you describe the lazy save and restore is only lazy when the secure world does not use the SVE/FP registers.
Hi,
on systems that don't support S-EL2, SPMC functionality mostly, if not all, resides in EL3
This is an implementation choice. E.g. OP-TEE implements an S-EL1 SPMC without needing SPMC logic at EL3 (beyond the SPMD as FF-A relayer).
If you consider the EL3 FF-A SPMC just recently added, yes most of the SPMC logic resides at EL3.
Thu, Jun 9
Hey Soby and Olivier, on systems that don't support S-EL2, SPMC functionality mostly, if not all, resides in EL3 right? Going by that convention, would it make sense to have SVE save and restore in EL3? We can make it part of SPMC code in EL3. For additional space we can make use of DDR carveout as Soby mentioned above. Moreover, if we make that context save and restore part enablement configurable at compile time, then platform can choose whether they want the functionality. Would it then be acceptable?
May 24 2022
Hi,
Today SEL2 unconditionally saves/restores FP/SIMD/SVE NS context on any SEL2 entry/exit.
I believe it could be optimized the way Soby is describing it by bullets 1,2,3,4.
It is worth noting that when SEL2 is not present (e.g. using the EL3 FF-A SPMC and a SEL1 TOS), the same lazy NS and TA contexts save/restore mechanism can be used by a SEL1 TOS and EL3 doesn't have to bother.
Hi Arve
May 23 2022
S-EL2 cannot lazily save and restore the non secure register state though since it cannot trap accesses by the normal world. I have not thought much about how to optimize a lazy save and restore mechanism where a lower exception level also uses lazy save and restore, but I don't think the secure world is fundamentally different from the normal world here. You can have lazy save and restore in NS-EL1, NS-EL2, S-EL1, S-EL2 and EL3. I think it is worthwhile to see how this can be optimized to avoid saving and restoring register states that will not be used, but I would like to see a solution that does not leak data between execution environments that are supposed to be isolated.
May 20 2022
TF-A works on a 6 month release cadence and we typically update the gcc toolchain to the latest released version along with the TF-A release. gcc versions we use are downloaded from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads.
Currently we don't update the toolchain to any versions newer than the one released here. We used the version 10.3-2021.07 with TF-A v2.6 release and will be updating to version 11.2-2022.02 with our upcoming v2.7 release which is planned for the end of May, 2022.
When you have a S-EL2 based system with possibly multiple S-EL1 partitions, it would be complex to implement a scheme where in EL3 will restore the right S-EL1 context on taking a trap during lazy save mechanism. In such systems, it is easier for S-EL2 to implement such a scheme since it is the manager for S-EL1 contexts.
Hey Olivier,
A similar issue was reported in the ticket https://developer.trustedfirmware.org/T984
Can you confirm if this issue is due to a bug in the toolchain itself?
May 11 2022
Reported bug in gcc 12.1.0
The issue is related to this GCC ticket:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Which is corrected in the official GCC 12.1 version.
May 7 2022
Apr 27 2022
Hi Peter,
So far this has been a deliberate design choice to avoid saving/restoring SVE state from EL3 mainly for BL31 footprint reasons (and performance if unconditionally done on each and every world switch). The vector register file ranges from 2KB to 8KB with 8 cores, and linearly scales to as many cores in the system (which can be hundreds in a server chipset). Apart from specific cases under discussion (SPM-MM or EL3 FF-A SPM), it is preferable to do this at lower EL e.g. a TOS at SEL1 (or Hafnium at SEL2). Do you have specific reasons why it cannot be done at lower EL?
You may also want to take a look at those options: ENABLE_SVE_FOR_NS and ENABLE_SVE_FOR_SWD
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/getting_started/build-options.rst#n409
Regards,
Olivier.
Apr 26 2022
Apr 20 2022
Mar 31 2022
Mar 28 2022
Hi Yuezhiran,
We are following this up internally. Could you please let us know what revision of Helios you have and whether you run linux? (Linux doesn't work around any Helios errata currently)
Mar 21 2022
As I understand it from the white paper (v1.6) from developer.arm.com there is research ongoing for the mitigation sequence for the Cortex- A65. Once known I believe TF-A reference mitigation patches will be developed.
I notice that relevant patches have been merged into the mainline branch except A65. will it be uploaded recently ?
Reference implementations of mitigations in TF-A for vulnerabilities in various CPU's were initially made available for public review in Gerrit. These have now after the opportunity for feedback been merged into the mainline branch.
Feb 16 2022
Feb 14 2022
Jan 17 2022
Hi @yuezhiran, I believe it's valid for this function to return 0. The bl1_plat_handle_post_image_load function is overridable by the platform, but we do not provide a mechanism for the platform to communicate the "acceptable" image IDs to the caller. We cannot therefore return an error if we receive an image ID that has no post-load process, because it may be called for any image (the FWU process does this here).
Ok, thanks a lot.
Dec 30 2021
Have you tried a more recent release? v2.6 is our latest tagged release or try tip of tree?
Dec 29 2021
Dec 28 2021
I am using Avenger96 and Buildroot and ran into similar issue.
Dec 25 2021
Dec 13 2021
Hi
As you mentioned, req_states will be NULL only if pwrlvl is not valid. However, in my opinion, many checks have been done earlier to the invocation of the function to make sure pwrlvl is valid. See lines 246 and 428 in lib/psci/psci_common.c file. Can you tell if you have noticed any issue in your platform with PSCI library?
Dec 9 2021
Thanks a lot.
A code coverage solution has been developed and is being tested before being rolled out in the production CI.
Thanks for your reply. So is there any way to calculate the coverage of TF-A(functions or codes)?
Jul 14 2021
The TF-A project uses the OpenCI project https://www.trustedfirmware.org/projects/open-ci/ to provide "Daily" and "Gerrit patch review" testing through a Jenkins infrastructure system with jobs visible here https://ci.trustedfirmware.org and these make use of tests defined in the TF-A Tests repository and from other reposititories. Please refer to the OpenCI documentation for more information https://tf-ci-users-guide.readthedocs.io/en/latest/
Jul 2 2021
Jun 24 2021
Given that there's no activity to get the submission rule issues in 9990 resolved, I followed CJKay's and jwerner's instructions and made https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10415, hopefully more ready for inclusion.