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 02F1574003E for ; Wed, 12 Mar 2025 06:32:44 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=yWxkzfKo1neqjkHhjIoqzdFpbC5pW+uBL3tB/OFFmpM=; 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=1741761164; v=1; x=1742020363; b=kMNQyFs2/VE4n8LkGt37ABCGNN7QUD6aazdJlhzhblQmVl2KIQzY+qyeiOVgSvIfOMFddf2l pf7RQe9En16xyTkt8eChOV5FN8cD3UYdIQH+yjxkkoPpwr4Yp9Ys83hNoz0rYJBMfj6G3I8yKSe irpG+ksh7687CWFp5JKF9Fa38Vn2fKfLerBZpx+K2nkTUhZ1F3dHxL8B3lsTKmWze5/SQFT2M2S Jp0GcfaTxj8HHEbHniWS15bVn7aZc/12XSkuGFiy7vasDkIdbHzoXYRY+sop2/Dm/CZ8o5bn5Lx bc9GpX3OWDUPm+52aGfL1QaMVSOzqtTcOT8hWq6jjNO6g== X-Received: by 127.0.0.2 with SMTP id BQYXYY7687511xuo2PRNb0g6; Tue, 11 Mar 2025 23:32:43 -0700 X-Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by mx.groups.io with SMTP id smtpd.web11.30920.1741761162411378977 for ; Tue, 11 Mar 2025 23:32:42 -0700 X-Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4769b16d4fbso10901141cf.2 for ; Tue, 11 Mar 2025 23:32:42 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWMoXtFkhNZbs1CLvRXrstndVJlpm1d0bmGQ1UfTChBThMJwgwXk9caO3pl2Aprz5TCPLr8rQ==@edk2.groups.io X-Gm-Message-State: RKVX2DintwIpZY8W2GRlBZvOx7686176AA= X-Gm-Gg: ASbGncsDT3T6yCzXNiDO4nGjGMkPf22zFD85IDlEIZdp5/fGYEttGfwspW24OsLsVlZ 95dqIbCvcwTTRWJ6fcMltpsyN3YiZs5271+fHPuYTjb7iz3PJwYMWUc/Q0dt18J3Q8vtCN0jxcm p1KlgM23EN/PN970sbkfMGpHDAVE8urJZDH5HHaRWlWlUabAo2D7vGsMs= X-Google-Smtp-Source: AGHT+IFzm5eivUJxB5dtNmircMKjZ/AgE6qfVOMDsIGul3z2ZpOrfA7GyRYoDfKdx+M//YBNQjZA2P6V/l+9cC0zZ2A= X-Received: by 2002:ad4:5f85:0:b0:6e8:f9e6:c4e2 with SMTP id 6a1803df08f44-6e9006c9878mr333551196d6.32.1741761161053; Tue, 11 Mar 2025 23:32:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kun Qin via groups.io" Date: Tue, 11 Mar 2025 23:32:30 -0700 X-Gm-Features: AQ5f1JrU3HrDQBfeYXPiXp1PXfszpmCFIpbIr1Ay9MVAFlhmaWBQcfYThWyAxoI Message-ID: Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 To: Sami Mujawar Cc: Leif Lindholm , "devel@edk2.groups.io" , 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: Tue, 11 Mar 2025 23:32:42 -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="00000000000049c8b506301f5fd2" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=kMNQyFs2; 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 --00000000000049c8b506301f5fd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the clarification, Sami. I will update the PR according to the discussion shortly. Regards, Kun On Mon, Mar 10, 2025 at 11:25=E2=80=AFAM Sami Mujawar wrote: > Hi All, > > I think we can only support FF-A 1.2 in StMM. The main reason being we > need Direct Req2, without which it would not be possible to target servic= es > hosted in StMM. e.g. when StMM hosts variable service and another service > say fTPM. Since both these services are within the same StMM partition we > need Direct Req2 to target messages to the fTPM service. > > Since Direct Req2 is only available since FF-A 1.2, it is a minimum > requirement for supporting in StMM. > > I think we just move to 18 registers. > > We can add a function to get the SMCCC version, but invoking that API > should be the caller=E2=80=99s responsibility and we should not make that= call > implicit in the library (i.e. calling in the SMC/HVC library constructor)= . > > As for the FF-A version check, I think we can bailout if the version is < > 1.2. > > Regards, > > Sami Mujawar > > > ------------------------------ > *From:* Kun Qin > *Sent:* 10 March 2025 17:13 > *To:* Leif Lindholm > *Cc:* devel@edk2.groups.io ; Sami Mujawar < > Sami.Mujawar@arm.com>; Olivier Deprez ; Yeo Reum > Yun ; Ard Biesheuvel ; > Manish Pandey2 > *Subject:* Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 > > 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 i= n > 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 > > 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. > -=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 (#121188): https://edk2.groups.io/g/devel/message/121188 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- --00000000000049c8b506301f5fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the=C2=A0clarification, Sami. I will update = the PR according to the discussion shortly.

Regards,
Kun

=
On Mon, Mar 10, 2025 at 11:25=E2=80= =AFAM Sami Mujawar <Sami.Mujawar= @arm.com> wrote:
Hi All,

I think we can only support FF-A 1.2 in StMM. The main reason being we need= Direct Req2, without which it would not be possible to target services hos= ted in StMM. e.g. when StMM hosts variable service and another service say = fTPM. Since both these services are within the same StMM partition we need Direct Req2 to target messages = to the fTPM service.=C2=A0

Since Direct Req2 is only available since FF-A 1.2, it is a minimum require= ment for supporting in StMM.=C2=A0

I think we just move to 18 registers.

We can add a function to get the SMCCC version, but invoking that API shoul= d be the caller=E2=80=99s responsibility and we should not make that call i= mplicit in the library (i.e. calling in the SMC/HVC library constructor).

As for the FF-A version check, I think we can bailout if the version is <= ; 1.2.=C2=A0

Regards,

Sami Mujawar=C2=A0


From: = Kun Qin <kuqin12@= gmail.com>
Sent: 10 March 2025 17:13
To: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
Cc: devel@= edk2.groups.io <devel@edk2.groups.io>; Sami Mujawar <Sami.Mujawar@arm.com>; Olivier D= eprez <Olivi= er.Deprez@arm.com>; Yeo Reum Yun <YeoReum.Yun@arm.com>; Ard Biesheuvel <<= a href=3D"mailto:ardb%2Btianocore@kernel.org" target=3D"_blank">ardb+tianoc= ore@kernel.org>; Manish Pandey2 <Manish.Pandey2@arm.com>
Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64=
=C2=A0
Hi=C2=A0Leif & Sami,

Thanks for providing the information and feedback. It sounds like the = SPMC@EL3 will get resolved with the=C2=A0TF-A PR, which will cover the comp= lete 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 chec= k in the SMC/SVC library to figure out the number of registers supported (t= hen 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.li= ndholm@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?token= =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 upstream, i.e. the FVP software stack with FF-A supp= ort has UEFI + TF-A (with SPMC+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 requirements.
>
> Levi has submitted a change to TF-A at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36018. I= f 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 <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 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 <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 that controls how many registers are used durin= g SMC calls to be backwards compatible, which is the PcdSxcUse18Registers a= pproach 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 runtim= e 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, wh= ich will not work if it is woken up by an=C2=A0 FFA_MSG_SEND_DIRECT_REQ2 ca= ll 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 information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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:

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

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

_._,_._,_
--00000000000049c8b506301f5fd2--