Hi Leif & Sami, Thanks for providing the information and feedback. It sounds like the SPMC@EL3 will get resolved with the TF-A PR, which will cover the complete usage of FF-A over SMC/SVC conduit with 18 registers. But do we want to move to 18-register all along? Or add a version check in the SMC/SVC library to figure out the number of registers supported (then FF-A library will also check this and bail if <= 1.1)? If we care to entertain that front, we can add it as well. Thanks, Kun On Mon, Mar 10, 2025 at 5:23 AM Leif Lindholm < leif.lindholm@oss.qualcomm.com> wrote: > Hi Sami, > > Thanks for the detailed summary. > > FF-A 1.1 is extremely unfortunate in how it fails to specify which > revision of SMCCC > it builds on, but thankfully 1.0 *did* explicitly call out 1.2. > > Right. So, yeah, since the conduit cannot care about how or why it's used, > it feels to me like either: > - FF-A 1.0/1,1 are violating the abstraction layers > or > - The existing TF-A implementation violates the specification. > > But I don't see anything in FF-A 1.0/1,1 implying parts of the SMC > calling convention > can be sidestepped, so personal hot take would be that the current > TF-A behaviour is > buggy, and that patch is a bugfix. > > Best Regards, > > Leif > > On Fri, 7 Mar 2025 at 14:20, Sami Mujawar via groups.io > wrote: > > > > Hi All, > > > > > > > > Following is a summary of the situation. > > > > > > > > FF-A 1.1 does not use more than 8 registers for parameter/return values. > > > > > > > > FF-A 1.2 introduced Direct Req/Resp 2 which utilises up to 18 registers > for parameter/return values. > > > > > > > > SMCCC 1.2 permitted the use of X4-X17 as return registers and X8-X17 as > argument registers. > > > > See ‘Appendix F: Changelog’, in the SMCCC specification, DEN0028, > version 1.6G > > > > (https://developer.arm.com/documentation/den0028/latest/) > > > > > > > > The section ‘2.4 Conduits’, in the FF-A 1.0 specification specifies that > the SMC conduit as described in the SMCCC 1.2 specification should be used, > see > https://documentation-service.arm.com/static/5fb7e8a6ca04df4095c1d65e?token= > > > > > > > > Considering the above one can infer that FF-A 1.0+ requires SMCCC 1.2 > which allows usage of X1-X17 as parameter and X0-X17 as return values when > using SMC64/HVC64 argument passing. See SMCCC 1.2 specification, Section > 2.7 SMC64/HVC64 argument passing. > > > > > > > > To support StandaloneMM (StMM), TF-A provides a SPMC+SPMD@EL3 which > currently supports FF-A 1.1 with partial support for Direct Req/Resp2 (i.e. > only 8 registers supported as parameter/return values). This was done to > have a minimal software stack for supporting FF-A with StMM in the > upstream, i.e. the FVP software stack with FF-A support has UEFI + TF-A > (with SPMC+SPMD@EL3) + StMM. > > > > > > > > Apparently, the SPMC+SPMD@EL3 support in TF-A is deprecated and no > further updates are planned. Therefore, to support a minimal software stack > we were looking at a build option in edk2 that supports configuring the use > of 8 registers. > > > > > > > > However, considering the fact that FF-A 1.0+ requires compliance with > SMCCC 1.2, I think we should just extend the SPMC+SPMD@EL3 support in > TF-A to support 18 registers. That way even though the SPMC+SPMD@EL3 > support in TF-A is deprecated, it is at least fully compliant with the > SMCCC 1.2 requirements. > > > > Levi has submitted a change to TF-A at > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36018. If > this TF-A change is approved and merged, the ArmCallSmc() implementation in > edk2 can just support 18 registers by default. > > > > > > > > Regards, > > > > > > > > Sami Mujawar > > > > > > > > From: Leif Lindholm > > Date: Thursday, 6 March 2025 at 22:58 > > To: Kun Qin > > Cc: Sami Mujawar , Olivier Deprez < > Olivier.Deprez@arm.com>, Yeo Reum Yun , > edk2-devel-groups-io , Ard Biesheuvel < > ardb+tianocore@kernel.org> > > Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 > > > > Hi Kun, > > > > My point is this has nothing to do with FF-A or likeliness. It is > > architecturally broken just from an SMCCC standpoint. > > But yes, I would like to hear more from Arm about the specific concern. > > > > Regards, > > > > Leif > > > > On Thu, 6 Mar 2025 at 20:42, Kun Qin wrote: > > > > > > Hi Leif, > > > > > > Thanks for the input. I agree that platforms supporting FF-A v1.2+ > will rely on SMCCC v1.1+, and thus platforms not supporting whole 18 > register usage are not complying with the spec. > > > > > > I think Sami, Levi, or Olivier could chime in for better insights on > their concerns about SPMC at EL3. As far as the setup we are using (Hafnium > as SPMC), the 18-register usage is good across all firmware entities. > > > > > > Regards, > > > Kun > > > > > > On Thu, Mar 6, 2025 at 1:42 AM Leif Lindholm < > leif.lindholm@oss.qualcomm.com> wrote: > > >> > > >> Hi Kun, > > >> > > >> On Thu, 6 Mar 2025 at 06:13, Kun Qin wrote: > > >> > > > >> > Hi ARM enthusiasts, > > >> > > > >> > I recently filed a PR to allow 18 register support for SMC/SVC > calls between UEFI and secure partition components: > https://github.com/tianocore/edk2/pull/10685/files. > > >> > > > >> > The main purpose of this change is to allow more registers to hold > values while doing FF-A transactions. In FF-A spec v1.2 and onward, the > section "FFA_MSG_SEND_DIRECT_REQ2" mentions that up to 18 general-purpose > registers can be used for such calls. However, the current SMC/SVC > implementation in EDK2 only supports up to 8 registers. > > >> > > > >> > There were some differing opinions on how to support this more > properly. Could you please review the PR and chime in on the email thread > about how to proceed with it? > > >> > > > >> > TL;DR: > > >> > > > >> > In conversations with ARM stakeholders, they revealed concerns > about using 18 registers all along because some older firmware components > on the secure side do not support full 18 register usage, and the returned > values may not be sane. Therefore, there is a need for a build flag that > controls how many registers are used during SMC calls to be backwards > compatible, which is the PcdSxcUse18Registers approach I went with in the > PR. > > >> > > >> I'm not sure I follow this one (and this is very much the reason I > > >> asked for email thread breakout - thank you). > > >> Code that relies on the 18 registers is relying on SMCCC >= 1.1. > > >> If code is relying on SMCCC >= 1.1, then it must verify that the > > >> secure side supports that > > >> by making an SMCCC_VERSION call. > > >> If that returns NOT_SUPPORTED, or that the version is 1.0, then the > > >> fewer-registers calling > > >> conventions MUST be used. Otherwise, the 18-register variant is safe. > > >> Am I missing something? > > >> > > >> If we're talking about supporting secure sides that don't comply with > > >> the spec, then I think > > >> that should be very much a "deal with broken secure firmware quirk" > > >> and not a different > > >> library. > > >> And in that case, it seems to me platform ports that felt the need to > > >> deal with broken > > >> secure sides should opt into that, with special handling in the > single library. > > >> > > >> If we're talking about supporting edk2 code that doesn't sanity check > > >> the version, then > > >> I'd suggest we fix the buggy edk2 code instead. > > >> > > >> Best Regards, > > >> > > >> Leif > > >> > > >> > The original approach of using the PCD was to make it a feature > flag so that all header files, assembly files, and C files will not even > compile the code that supports more than 8 registers if not needed. But > that would involve the PCDs getting pre-processed by the build framework, > and all components using the ArmSmcLib would thus have to add the PCD in > their inf files. So instead, we went with the runtime code evaluation. > > >> > > > >> > On the PR, Sami suggested creating a new interface that supports > SMC with 18 registers and making the PCD control which function to call. > For FF-A functions that only involve 8 registers or under, the caller > should just use the legacy interfaces. But the issue is, once Standalone MM > hands off the control using an 8 register SMC call, it will only be able to > process 8 register incoming requests, which will not work if it is woken up > by an FFA_MSG_SEND_DIRECT_REQ2 call using 18 registers. > > >> > > > >> > Any input is appreciated. > > >> > > > >> > Regards, > > >> > Kun > > > > 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. > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121175): https://edk2.groups.io/g/devel/message/121175 Mute This Topic: https://groups.io/mt/111543575/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-