From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 1ADE1940662 for ; Mon, 10 Mar 2025 17:13:18 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=HrH2E7L0SvWzzMLT/QIeHv/Kc+xwFRnkd2OFZwNHHJY=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240830; t=1741626798; v=1; x=1741885997; b=HwBcO67BwMaZJp4zQGUqFoLleJGnaYB6TK1cM09a5HHmgYq86i/jYSWbZUWpqEgC3j+UvvIn i/qo1ud+4E/FQ/N0dqKHtIDTKeqHGc65MAiT+o0ZQJmjG3ancWNihihM/PHY4npXeBG5851OtUj Fyx2xBR5CiDlsITulBE5oWO6MhUQP3VCfRdlvODktef2jxCvkR5MQo0Gc8CqQi51EpKa/gSQuCB KpGXNo99IzMB86qcSSmIqCjd8wvPu1uXgl/OPYED/C+1PwmBL724Qq2A7xvLltUS8K7lA3o82Mj EVyrrGvoZ+DGZmrbBZyjGzUxUVTeaW2/Cn+ZKSShXA3Ew== X-Received: by 127.0.0.2 with SMTP id 2o5sYY7687511xLBpcVQeGo1; Mon, 10 Mar 2025 10:13:17 -0700 X-Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by mx.groups.io with SMTP id smtpd.web10.44032.1741626796330024637 for ; Mon, 10 Mar 2025 10:13:16 -0700 X-Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-7c556b7bb12so85688085a.0 for ; Mon, 10 Mar 2025 10:13:16 -0700 (PDT) X-Gm-Message-State: Gn3hkGETSmZlwCidhBLI90bNx7686176AA= X-Gm-Gg: ASbGnctGSEBb3LfNkbyv60/zokuXn5obnN5s4pvxc755AI8Zepse27Rn9mcNklSfGCv c/2jzmblHgXZ4rGYzdEA/Q4G+atJqI97VsmF06MOcVl1H6+kZWxtk135Qm4wknTzrPfJL9ob5A9 lO/z+Vmr0FU5zi4q5O9FiqlIma6kg/zznI7df3k8g7MWVM6xxp0MfzWcAyCnC/I0JY9g== X-Google-Smtp-Source: AGHT+IEvuYkTwd+pSoPE48TkOnY1ZUJGq2KkBep+HXoLdXMDT90+0RugXDn58oMdiqHcaoXlgIETUhvw9iewnoHnmG8= X-Received: by 2002:a05:6214:411b:b0:6e6:61f1:458a with SMTP id 6a1803df08f44-6e9005e8f70mr165646376d6.14.1741626795163; Mon, 10 Mar 2025 10:13:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kun Qin via groups.io" Date: Mon, 10 Mar 2025 10:13:04 -0700 X-Gm-Features: AQ5f1Jqv1ZCfCIxuvuMhCrUCyuFzOgfNIZ0kKxM2zzpKTO82cXK5wqV5l1Bdgrs Message-ID: Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 To: Leif Lindholm Cc: devel@edk2.groups.io, sami.mujawar@arm.com, Olivier Deprez , Yeo Reum Yun , Ard Biesheuvel , Manish Pandey2 Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Mon, 10 Mar 2025 10:13:16 -0700 Resent-From: kuqin12@gmail.com Reply-To: devel@edk2.groups.io,kuqin12@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: multipart/alternative; boundary="0000000000007504520630001637" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=HwBcO67B; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --0000000000007504520630001637 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 <=3D 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=E2=80=AFAM 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 =E2=80=98Appendix F: Changelog=E2=80=99, in the SMCCC specification= , DEN0028, > version 1.6G > > > > (https://developer.arm.com/documentation/den0028/latest/) > > > > > > > > The section =E2=80=982.4 Conduits=E2=80=99, in the FF-A 1.0 specificati= on specifies that > the SMC conduit as described in the SMCCC 1.2 specification should be use= d, > see > https://documentation-service.arm.com/static/5fb7e8a6ca04df4095c1d65e?tok= en=3D > > > > > > > > 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 whe= n > 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 sta= ck > we were looking at a build option in edk2 that supports configuring the u= se > 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 (Hafni= um > as SPMC), the 18-register usage is good across all firmware entities. > > > > > > Regards, > > > Kun > > > > > > On Thu, Mar 6, 2025 at 1:42=E2=80=AFAM 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 returne= d > 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 >=3D 1.1. > > >> If code is relying on SMCCC >=3D 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 wit= h > > >> 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 t= o > > >> 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 chec= k > > >> 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 th= e > information in any medium. Thank you. > >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --0000000000007504520630001637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Leif & Sami,

Thanks for pro= viding the information and feedback. It sounds like the SPMC@EL3 will get r= esolved with the=C2=A0TF-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/SV= C library to figure out the number of registers supported (then FF-A librar= y will also check this and bail if <=3D 1.1)? If we care to entertain th= at front, we can add it as well.

Thanks,
Kun

On Mon, Mar 10, 2025 at 5:23=E2=80=AFAM Lei= f Lindholm <leif.lindh= olm@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 us= ed,
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
<sami.mujawar=3Da= rm.com@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 value= s.
>
>
>
> FF-A 1.2 introduced Direct Req/Resp 2 which utilises up to 18 register= s for parameter/return values.
>
>
>
> SMCCC 1.2 permitted the use of X4-X17 as return registers and X8-X17 a= s argument registers.
>
> See =E2=80=98Appendix F: Changelog=E2=80=99, in the SMCCC specificatio= n, DEN0028,=C2=A0 version 1.6G
>
> (https://developer.arm.com/documentation= /den0028/latest/)
>
>
>
> The section =E2=80=982.4 Conduits=E2=80=99, in the FF-A 1.0 specificat= ion specifies that the SMC conduit as described in the SMCCC 1.2 specificat= ion should be used, see https://documentation-service.arm.com/static/5fb7e8a6ca04df4095c1d65e?tok= en=3D
>
>
>
> 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 cu= rrently supports FF-A 1.1 with partial support for Direct Req/Resp2 (i.e. o= nly 8 registers supported as parameter/return values).=C2=A0 This was done = to have a minimal software stack for supporting FF-A with StMM in the upstr= eam, i.e. the FVP software stack with FF-A support has UEFI + TF-A (with SP= MC+SPMD@EL3) + StMM.
>
>
>
> Apparently, the SPMC+SPMD@EL3 support in TF-A is deprecated and no fur= ther updates are planned. Therefore, to support a minimal software stack we= were looking at a build option in edk2 that supports configuring the use o= f 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 requi= rements.
>
> 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() imp= lementation in edk2 can just support 18 registers by default.
>
>
>
> Regards,
>
>
>
> Sami Mujawar
>
>
>
> From: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
> Date: Thursday, 6 March 2025 at 22:58
> To: Kun Qin <kuqin12@gmail.com>
> Cc: Sami Mujawar <Sami.Mujawar@arm.com>, Olivier Deprez <Olivier.Deprez@arm.com>, = Yeo Reum Yun <Y= eoReum.Yun@arm.com>, edk2-devel-groups-io <devel@edk2.groups.io>, Ard Biesh= euvel <= 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 <kuqin12@gmail.com> 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 regi= ster 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 (Haf= nium as SPMC), the 18-register usage is good across all firmware entities.<= br> > >
> > Regards,
> > Kun
> >
> > On Thu, Mar 6, 2025 at 1:42=E2=80=AFAM 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 S= MC/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 registe= rs to hold values while doing FF-A transactions. In FF-A spec v1.2 and onwa= rd, 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 thi= s more properly. Could you please review the PR and chime in on the email t= hread about how to proceed with it?
> >> >
> >> > TL;DR:
> >> >
> >> > In conversations with ARM stakeholders, they revealed co= ncerns about using 18 registers all along because some older firmware compo= nents on the secure side do not support full 18 register usage, and the ret= urned values may not be sane. Therefore, there is a need for a build flag t= hat controls how many registers are used during SMC calls to be backwards c= ompatible, 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 >= =3D 1.1.
> >> If code is relying on SMCCC >=3D 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, th= en 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&#= 39;t comply with
> >> the spec, then I think
> >> that should be very much a "deal with broken secure firm= ware 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 t= he single library.
> >>
> >> If we're talking about supporting edk2 code that doesn= 9;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. B= ut 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 calle= r 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 woke= n up by an=C2=A0 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 c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#121175) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--0000000000007504520630001637--