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 <kuqin12@gmail.com> 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
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121160): https://edk2.groups.io/g/devel/message/121160
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]
-=-=-=-=-=-=-=-=-=-=-=-