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