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 D40E1941CD4 for ; Thu, 6 Mar 2025 20:42:31 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=aS5CBXsGviXGgp/dOZtIwFj7UDiq+smlxrJfqRVNHH0=; 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=1741293751; v=1; x=1741552950; b=j8QpPbZB3EVLNPtEIQ3A3sGf8M4UuAaiD0Q1kQIEnuIk0EUUlA8N78Ub23lNae3u9QWOICmV 4lwBxTVRFMF/+naZpdd4kJMx2bnx8twX/qiowDoH+lQ/cyPdeLmzACfEchNPkZ6XvUtXBe88t46 iCgMaxhG/pPdcgXkY1OrcFvm1mRp63IoKqOhy55/MdG6ZKYkgo5+HlhLasOS+oyYiSN0VupjISh teEMo8XW+cQ6trKFVT8CqRjDr2Ov/yRHyn9BzsFFcSMDn/fuwPYpBsOfooJH62c0Txnaby5oDFI 94tmWcoysocFqv4us9oEQ9J09l3XmZqfkVpTTCu/OGaeA== X-Received: by 127.0.0.2 with SMTP id BVroYY7687511x1JubQqrGwj; Thu, 06 Mar 2025 12:42:30 -0800 X-Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) by mx.groups.io with SMTP id smtpd.web10.5107.1741293749342513250 for ; Thu, 06 Mar 2025 12:42:29 -0800 X-Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6dd15d03eacso10661626d6.0 for ; Thu, 06 Mar 2025 12:42:29 -0800 (PST) X-Gm-Message-State: OAuaXfYh4dYYHKAOYq5g21cMx7686176AA= X-Gm-Gg: ASbGncuFZey6wfUItrl6cuQFUNz1SdkqOvpPxZvVtnN2OcyfP6mgd2pCslucah14j6m 5fZYcjQ6BIH28PapGyi5QRcQb73mGAm7GNfnbYwihK2xgJPvp6aR5ubJg+5aLideVUTYV58bqK2 7MY1AsxWv+m1bhoeLAa0QivIYy3cR8R+klg1v1X1VoWZsYDuRTLrh8DNo= X-Google-Smtp-Source: AGHT+IH0gcX63RtKxD4QDKWVcSHCtLgteLRSyb+/jL9rEVCmQ0prXb3F98uo7mh8GYf0AQAh6kg4u5O5ZkSlaPqk2/c= X-Received: by 2002:a05:6214:5005:b0:6d8:b733:47c with SMTP id 6a1803df08f44-6e8ff7fcc82mr17767636d6.22.1741293748362; Thu, 06 Mar 2025 12:42:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kun Qin via groups.io" Date: Thu, 6 Mar 2025 12:42:16 -0800 X-Gm-Features: AQ5f1JqyR7LFvf_PwDKVsORvms8vmDI5NAWR9iwM1aYDNkCu9JTOW9s4jt4v_bg Message-ID: Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 To: Leif Lindholm , Sami Mujawar , olivier.deprez@arm.com, yeoreum.yun@arm.com Cc: edk2-devel-groups-io , Ard Biesheuvel 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: Thu, 06 Mar 2025 12:42:29 -0800 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="000000000000522a39062fb28b39" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=j8QpPbZB; 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 --000000000000522a39062fb28b39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Leif Lindholm 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 th= e > secure side do not support full 18 register usage, and the returned value= s > may not be sane. Therefore, there is a need for a build flag that control= s > 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 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 woul= d > 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 in= f > 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 hand= s > 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 > -=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 (#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] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --000000000000522a39062fb28b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Leif,

Thanks for the input. I agree = that platforms supporting FF-A v1.2+ will rely on SMCCC v1.1+, and thus pla= tforms not supporting whole 18 register usage are not complying with the sp= ec.

I think Sami, Levi, or Olivier could chime in = for better insights on their concerns about SPMC at EL3. As far as the setu= p 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=E2=80=AFAM Leif Lindholm <= ;leif.lindholm@oss.qualco= mm.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 b= etween 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 val= ues while doing FF-A transactions. In FF-A spec v1.2 and onward, the sectio= n "FFA_MSG_SEND_DIRECT_REQ2" mentions that up to 18 general-purpo= se registers can be used for such calls. However, the current SMC/SVC imple= mentation in EDK2 only supports up to 8 registers.
>
> There were some differing opinions on how to support this more properl= y. Could you please review the PR and chime in on the email thread about ho= w to proceed with it?
>
> TL;DR:
>
> In conversations with ARM stakeholders, they revealed concerns about u= sing 18 registers all along because some older firmware components on the s= ecure side do not support full 18 register usage, and the returned values m= ay not be sane. Therefore, there is a need for a build flag that controls h= ow many registers are used during SMC calls to be backwards compatible, whi= ch 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 wi= th
the spec, then I think
that should be very much a "deal with broken secure firmware quirk&quo= t;
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 libr= ary.

If we're talking about supporting edk2 code that doesn't sanity che= ck
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 s= o 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 comp= onents using the ArmSmcLib would thus have to add the PCD in their inf file= s. So instead, we went with the runtime code evaluation.
>
> On the PR, Sami suggested creating a new interface that supports SMC w= ith 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 t= he 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=C2= =A0 FFA_MSG_SEND_DIRECT_REQ2 call using 18 registers.
>
> Any input is appreciated.
>
> Regards,
> Kun
_._,_._,_
Groups.io Links:

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

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

_._,_._,_
--000000000000522a39062fb28b39--