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 01730740032 for ; Thu, 6 Mar 2025 06:13:32 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=htskABJQEtsniVQGDJGdfCwr8IbH7SEWiQO/EOFykqg=; c=relaxed/simple; d=groups.io; h=MIME-Version: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=1741241612; v=1; x=1741500811; b=m7Y77i+HdPhjaDFKxy7IEPjjplFSFEfcdqyL0m5mJ1cuQ+2R3dpVS5MM1i4TO6qpBzg1+J9G imqLYSGIK27z5kPJDjQCNtQTSbZl6Xo6SzJ29ossEDkt+nTpugvmBTHthXwwSlQUs+vX3oBzyWG 4BvQaTQfPkEXv67pNOSSFIu0XiNN9CoLzf1sVKhagjoSUufKo7TaEwuXGmrsMLO+iJdOPkEdbbF oI3QwNcDIbLWTRGru/HEUmftyk/6cuAHZQSxiyGORnl3AdHkADuCL45q3/SjpIlTacJgznlsWAl uZcFZy5qnrsIgb57FysFdNDUinFMQha47gAw2S8B4iIXw== X-Received: by 127.0.0.2 with SMTP id gnU9YY7687511xbux2QhHQXL; Wed, 05 Mar 2025 22:13:31 -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.web11.6336.1741241605661859871 for ; Wed, 05 Mar 2025 22:13:25 -0800 X-Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6e8f43c1fa0so3535846d6.3 for ; Wed, 05 Mar 2025 22:13:25 -0800 (PST) X-Gm-Message-State: sCOTq2yBhCFBnGPcu5nSr9b3x7686176AA= X-Gm-Gg: ASbGncuj57VuuO7A8FFqxCFXTaCSyA/ms6aHiLSmQe3HDcLVK6YV/H+p7ruzOAhFwQD G1WGYtH44q9dAGImhyKCgocZ4FuNU6c4ptNDLJmnDoLi7SwIFEY8U2RQRZtllWjG6iJkUiMa6of F+xzKtzEQIOPWDmrOMua0+F/LX+5Bvu6ALhR8ZL5fhWGy0w4iOiEke6xM= X-Google-Smtp-Source: AGHT+IFpBKjCsYpiE0ga8WOOavKz4W9AXpOF8J8yyIkzVuIFjU9dVHOBbccjKgjvnHPH+zMMoT1uq7wKPEjrsauDmj0= X-Received: by 2002:a05:6214:528a:b0:6e8:fa38:46aa with SMTP id 6a1803df08f44-6e8fa38499cmr3242896d6.33.1741241604450; Wed, 05 Mar 2025 22:13:24 -0800 (PST) MIME-Version: 1.0 From: "Kun Qin via groups.io" Date: Wed, 5 Mar 2025 22:13:13 -0800 X-Gm-Features: AQ5f1Jp5tofc-X-pmcyaOy7kuGO4RuhSvl4Vmb5gA07KlRMvM865YSwmnTKbE_U Message-ID: Subject: [edk2-devel] 18 register support for SMC/SVC on AARCH64 To: edk2-devel-groups-io Cc: Leif Lindholm , Sami Mujawar , Ard Biesheuvel , olivier.deprez@arm.com 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: Wed, 05 Mar 2025 22:13:25 -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="0000000000004d2f98062fa66768" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=m7Y77i+H; 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 --0000000000004d2f98062fa66768 Content-Type: text/plain; charset="UTF-8" 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. 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121153): https://edk2.groups.io/g/devel/message/121153 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] -=-=-=-=-=-=-=-=-=-=-=- --0000000000004d2f98062fa66768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi ARM enthusiasts,

I recently filed a PR t= o allow 18 register support for SMC/SVC calls between UEFI and secure parti= tion 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 "F= FA_MSG_SEND_DIRECT_REQ2" mentions that up to 18 gene= ral-purpose registers can be used for such calls. However, the current SMC/= SVC implementation in EDK2 only supports up to 8 registers.

There we= re 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 ol= der 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.

The original approach of usi= ng 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-proc= essed 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 r= untime code evaluation.

On the PR, Sami suggested creating a new int= erface 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 unde= r, 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 i= f 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 (#121153) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--0000000000004d2f98062fa66768--