+Jose (SMCCC maintainer)
________________________________ From: boot-architecture boot-architecture-bounces@lists.linaro.org on behalf of François Ozog francois.ozog@linaro.org Sent: Wednesday, May 13, 2020, 6:51 PM To: Boot Architecture Mailman List Subject: [RFC] SMC yielding Trusted OS call discrepancies
Hi,
Trusted OSes such as OP-TEE or QSEE are using SMC yielding function numbers in the 0x32000000-0x3200006F range. The SMC calling conventions are specified in DEN0028 which has currently three versions (see below).
To the best of my understanding, the use of this range is: - compliant with version a - acceptable with version b - somewhat contradicting with version c
version a analysis: table 6.1 states that the trusted OS standard calls should be in the range "0x02000000-0x7FFFFFFF", so the selected range is good. Section 2.1 that defines a bit structure for function numbers for both yielding and fast calls and the range is compatible. The range covered by table 6.1 for Trusted OS calls is however much bigger that the bit structure definition. As a result a 0x02000000 call is a yielding Trusted OS call as per table 6.1 but a Yielding SiP call as per section 2.1.
version b analysis: table 6.2 states that the trusted OS yielding calls should be in the range "0x02000000-0x1FFFFFFF" and that the range "0x20000000-0x7FFFFFFF" is "reserved for future expansion of Trusted OS Yielding Calls". So the range is acceptable but poorly selected. There is the same inconsistency as version a when it comes to qualifying a 0x02000000 call: table 6.2 says it is a Trusted OS yielding call, section 2.5 says it is a yielding SiP call.
version c analysis: section 2.5.1 now clearly states that the bit structure is only for Fast calls. and both section 2.52 and table 6.2 state that Trusted OS calls should be in the range "0x02000000-0x1FFFFFFF". both section 2.5.2 and 6 qualify the 0x02000000 call as a Trusted OS yielding call.
I think that version a and b have inconsistent between chapter 2 and 6. Version c brings internal consistency but seems to be not in alignment with best practices.
I guess there is a need to both address internal document inconsistency and better reflect existing products.
Any thoughts?
-FF
version a: https://drive.google.com/file/d/1OclQZk0o28n5ZUIYeTuFICbLiGWzOvxH/view?usp=s... version b: https://static.docs.arm.com/den0028/b/ARM_DEN0028B_SMC_Calling_Convention.pd... version c: https://static.docs.arm.com/den0028/c/Q1-ARM-DEN-0028_SMC_Calling_Convention... _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.