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 EB313943F76 for ; Mon, 10 Mar 2025 12:23:59 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=M7lx3R5ppLbAJZpiGCAYiyNeKgw/G3htxm00EwRxM94=; 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:Content-Transfer-Encoding; s=20240830; t=1741609439; v=1; x=1741868638; b=S51Ubc7P8ZuAzEopXojfLCsZcKr/1k8TqkyyTsHsqxTeXwAiPjLTdVWqNG7RtiLZLcEaK6au vRbu+q5jFA2WBkweKvNXpXaaU0TaSjoRUgs+NKcVYWb8JIBhCGxVt4mR9xj9v8aY7BeB+4Inutk 17RJPftafTK4poZxLMtuSY2W/Of5j4TbBVbOsVY93Z2GhWmLMu053om76X3NeGRLELAdoc0xok2 SQyQ18Ryz0rzj9ZBNO5icHGCS5yZCy8tFcrnUbegjnNN09apsseoPpwRLlqD2XDPheenFoFJc7j lcnPOxiEhGC8KzFzuHdn6cx+gmQbLO5tbl+0g5FTwYE+A== X-Received: by 127.0.0.2 with SMTP id hLeeYY7687511x53fg9Y8QAo; Mon, 10 Mar 2025 05:23:58 -0700 X-Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by mx.groups.io with SMTP id smtpd.web10.36266.1741609437824574103 for ; Mon, 10 Mar 2025 05:23:57 -0700 X-Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 52A9xOeK029796 for ; Mon, 10 Mar 2025 12:23:57 GMT X-Received: from mail-yb1-f199.google.com (mail-yb1-f199.google.com [209.85.219.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 458eypcr0c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 10 Mar 2025 12:23:57 +0000 (GMT) X-Received: by mail-yb1-f199.google.com with SMTP id 3f1490d57ef6-e5740c858beso4917564276.2 for ; Mon, 10 Mar 2025 05:23:57 -0700 (PDT) X-Gm-Message-State: gyxYdphHTK4iPeVsB8tBlwT1x7686176AA= X-Gm-Gg: ASbGnct5IWwpYpn5gW/Ae2F7mlK+yA5TJFbpOm0Rn56booFKursl8y76Ewnm5xTXuzA 7Ayf/RUNCR5C5j59Mg3Omdu8dNYKA8sykWsOOdM2XAfxrMltX2A8vBasKBwNS5jPd0EOw2pbzmB A8m/1EsKkwG40E6tPXDouv0odLl+lVww== X-Received: by 2002:a05:6902:2882:b0:e5b:248a:bf3a with SMTP id 3f1490d57ef6-e635c1d9824mr14573839276.30.1741609435828; Mon, 10 Mar 2025 05:23:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFR6/ktV38xzohISVgfkV765g8I/ZGz2SOXZ/mpOnvDDZCqctU4HpbXsDoVj5K2gLccpnZVNfml7v58M9MNTbo= X-Received: by 2002:a05:6902:2882:b0:e5b:248a:bf3a with SMTP id 3f1490d57ef6-e635c1d9824mr14573820276.30.1741609435497; Mon, 10 Mar 2025 05:23:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Leif Lindholm via groups.io" Date: Mon, 10 Mar 2025 12:23:44 +0000 X-Gm-Features: AQ5f1JpSdi3RJ6f-ahWBmdyQ4tejwIKyh_hbQCaAuLrYOFaCyuyFwwBXQUs7rqg Message-ID: Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 To: devel@edk2.groups.io, sami.mujawar@arm.com Cc: Kun Qin , Olivier Deprez , Yeo Reum Yun , Ard Biesheuvel , Manish Pandey2 X-Authority-Analysis: v=2.4 cv=A9yWP7WG c=1 sm=1 tr=0 ts=67ced9dd cx=c_pps a=bcYUF9iMMBfaiOy0M+g+3g==:117 a=IkcTkHD0fZMA:10 a=Vs1iUdzkB0EA:10 a=7CQSdrXTAAAA:8 a=b45o4kL6AAAA:8 a=NEAV23lmAAAA:8 a=EUspDBNiAAAA:8 a=pGLkceISAAAA:8 a=VwQbUJbxAAAA:8 a=KZzf7U-Ahb4t2MB1lwoA:9 a=QEXdDO2ut3YA:10 a=4AvBJ3eyfGLrynxe6Eyb:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=dhdsR-PFWuPJUldTnwXm:22 X-Proofpoint-ORIG-GUID: lMiq6ErUe4FLHQErCDmAch3ILlniXy1l X-Proofpoint-GUID: lMiq6ErUe4FLHQErCDmAch3ILlniXy1l 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 05:23:57 -0700 Resent-From: leif.lindholm@oss.qualcomm.com Reply-To: devel@edk2.groups.io,leif.lindholm@oss.qualcomm.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=S51Ubc7P; 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 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 f= or parameter/return values. > > > > SMCCC 1.2 permitted the use of X4-X17 as return registers and X8-X17 as a= rgument 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 specification= specifies that the SMC conduit as described in the SMCCC 1.2 specification= should be used, see https://documentation-service.arm.com/static/5fb7e8a6c= a04df4095c1d65e?token=3D > > > > Considering the above one can infer that FF-A 1.0+ requires SMCCC 1.2 whi= ch allows usage of X1-X17 as parameter and X0-X17 as return values when usi= ng SMC64/HVC64 argument passing. See SMCCC 1.2 specification, Section 2.7 S= MC64/HVC64 argument passing. > > > > To support StandaloneMM (StMM), TF-A provides a SPMC+SPMD@EL3 which curre= ntly 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 furthe= r updates are planned. Therefore, to support a minimal software stack we we= re looking at a build option in edk2 that supports configuring the use of 8= registers. > > > > However, considering the fact that FF-A 1.0+ requires compliance with SMC= CC 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 requirem= ents. > > 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 mer= ged, 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 , Yeo Reum Yun , edk2-devel-groups-io , Ard Biesheuvel > 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 u= sage are not complying with the spec. > > > > I think Sami, Levi, or Olivier could chime in for better insights on th= eir concerns about SPMC at EL3. As far as the setup we are using (Hafnium a= s 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 v= alues while doing FF-A transactions. In FF-A spec v1.2 and onward, the sect= ion "FFA_MSG_SEND_DIRECT_REQ2" mentions that up to 18 general-purpose regis= ters can be used for such calls. However, the current SMC/SVC implementatio= n in EDK2 only supports up to 8 registers. > >> > > >> > There were some differing opinions on how to support this more prope= rly. 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, w= hich 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 compil= e 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 co= mponents using the ArmSmcLib would thus have to add the PCD in their inf fi= les. 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 F= F-A functions that only involve 8 registers or under, the caller should jus= t 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 conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n 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 (#121166): https://edk2.groups.io/g/devel/message/121166 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-