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 A5E8274004A for ; Thu, 6 Mar 2025 09:42:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=/Lsjru1tFwKgtggfHo2M9e/QCiI4ryj9bON4cmeaqm0=; 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=1741254168; v=1; x=1741513367; b=nsqE7GzuxRNSD52kZ33nvqSMll76ZusLuRcDNzUau5DYYzmkdts8ny4bWoLjl6y/Y4GpiAp9 7hdj4WlJvVrAk6frimertFRy6OCSj8f8fWG+DBdZ/L6P9S6P3v9LQyVFjoxKSw8VqD4b5bPjuth wxjid1uNHaaepFGQeb9M0noEO2U1COq4jRzMJxOY8YLA7ljoBc3agEZ2NWDqmuXysfJy/L27cYt sbdqC65KYVGoi2A3RFcTHrZUftqQbNce/Dbtd8JcPuYazp1eyHztmBUgbJbqQDEej8rdigp52nG azRtu3yGIQ9Te76J6V3BE/RMchYDasQSsgjrTNvwf4KWw== X-Received: by 127.0.0.2 with SMTP id ajrXYY7687511x0fvp4Mnzey; Thu, 06 Mar 2025 01:42:47 -0800 X-Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by mx.groups.io with SMTP id smtpd.web11.9026.1741254161506301500 for ; Thu, 06 Mar 2025 01:42:41 -0800 X-Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5268iHXH016108 for ; Thu, 6 Mar 2025 09:42:41 GMT X-Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 455p6vrh4b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 06 Mar 2025 09:42:40 +0000 (GMT) X-Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-6feb1097d64so6695587b3.2 for ; Thu, 06 Mar 2025 01:42:40 -0800 (PST) X-Gm-Message-State: CtICHXu627qfC0PTUEZg6tyjx7686176AA= X-Gm-Gg: ASbGncvRJjrI95V2an9m+fOHQmccT8B+SWCdsiuBNCUwQ+5pRjxmejn7Hr0qO2Yxcu6 PrLjfndgad0g7RBXRzModhu87Hag4MG3O2IRqXHFeeLz8qTQU83iBOYur3jUGIt2JEwal3y3gO4 sqizAfuZlWR4qr3+bb8ezgroliDKwTEQ== X-Received: by 2002:a05:690c:6aca:b0:6fb:b37f:2072 with SMTP id 00721157ae682-6fda2fa1241mr95213477b3.22.1741254159806; Thu, 06 Mar 2025 01:42:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IFdDmc/JRZ1vibypa4gk3diEarIhzaiOgyL8KPvOx8Nxtpg5LotVL7QwejwNj6pOi5/7yRjiSFDxaL7r30LtSQ= X-Received: by 2002:a05:690c:6aca:b0:6fb:b37f:2072 with SMTP id 00721157ae682-6fda2fa1241mr95213267b3.22.1741254159426; Thu, 06 Mar 2025 01:42:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Leif Lindholm via groups.io" Date: Thu, 6 Mar 2025 09:42:28 +0000 X-Gm-Features: AQ5f1JpBq6pLaTC-sdn-u5AjziGBtAM28520RrUVHYtmj6X8M6Bp_K7rzzgqDH0 Message-ID: Subject: Re: [edk2-devel] 18 register support for SMC/SVC on AARCH64 To: Kun Qin Cc: edk2-devel-groups-io , Sami Mujawar , Ard Biesheuvel , olivier.deprez@arm.com X-Proofpoint-GUID: 4g-6T0MI0xAyqM8peaTVLf7rQUhphCwu X-Authority-Analysis: v=2.4 cv=LYfG6ifi c=1 sm=1 tr=0 ts=67c96e10 cx=c_pps a=NMvoxGxYzVyQPkMeJjVPKg==:117 a=IkcTkHD0fZMA:10 a=Vs1iUdzkB0EA:10 a=NEAV23lmAAAA:8 a=pGLkceISAAAA:8 a=LjIIEGzCdFOdMG-gh_8A:9 a=QEXdDO2ut3YA:10 a=kLokIza1BN8a-hAJ3hfR:22 X-Proofpoint-ORIG-GUID: 4g-6T0MI0xAyqM8peaTVLf7rQUhphCwu 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 01:42:41 -0800 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=nsqE7Gzu; 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 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 betw= een 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 t= o proceed with it? > > TL;DR: > > In conversations with ARM stakeholders, they revealed concerns about usin= g 18 registers all along because some older firmware components on the secu= re 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. 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 libr= ary. 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 t= hat 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 inv= olve the PCDs getting pre-processed by the build framework, and all compone= nts 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 f= unctions 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 reg= ister incoming requests, which will not work if it is woken up by an FFA_M= SG_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 (#121156): https://edk2.groups.io/g/devel/message/121156 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-