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 009DAAC12DB for ; Mon, 3 Jun 2024 16:47:28 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=aQFW4c7QqyMt2LHCLeR5r1VEJDgEAQroL0/szLjUFC0=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:CC:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20240206; t=1717433248; v=1; b=0iKuIdm20ICUjwZed4pJsP8eRxozEO2GsbWl2SmYC5eLXwlAUdEf5ij5iX8FWcUrl/Uq3rSP FyCbZoaH+cTDhlrmalvacYJBiSow+zHpW0+8RUXCWEvKdYy7e/wUkXj6UxpYPD8WJCHtsE+VbCj h3QmieB6cX6CriXxPOCdkQeUoWwTYYvFQ6KukmrSGF/dPef1S3Gfe83lQ35PhCMnPcQ88BJ62L6 2MjLRhAa1tpgpyr6Hon2jvj5OirrKeuExgulwE+9RwNXi28l+XYmeEE0f3Ao5HKeUhpZB+QogWW jf6ceAztOW+IXLoiDWr4G6HIKO9NUDjlP0+LbZhvqe7yg== X-Received: by 127.0.0.2 with SMTP id hs9tYY7687511xgaU3I4Ckp0; Mon, 03 Jun 2024 09:47:27 -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.89007.1717433246835472196 for ; Mon, 03 Jun 2024 09:47:26 -0700 X-Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 453A7GpZ027645; Mon, 3 Jun 2024 16:47:23 GMT X-Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3yfw5wmf5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Jun 2024 16:47:23 +0000 (GMT) X-Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.45.79.139]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 453GlMsG019069 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Jun 2024 16:47:22 GMT X-Received: from [10.111.137.228] (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Mon, 3 Jun 2024 09:47:21 -0700 Message-ID: Date: Mon, 3 Jun 2024 17:47:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] ArmCallSmc() and SMCCC specification To: Marcin Juszkiewicz , CC: Ard Biesheuvel , Sami Mujawar References: <28f07a88-f664-43f4-871d-b5d0b82c7727@linaro.org> From: "Leif Lindholm" In-Reply-To: <28f07a88-f664-43f4-871d-b5d0b82c7727@linaro.org> X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-GUID: qeP1NaWcn2PUaWeJuCb5w_ZpUt_twXCJ X-Proofpoint-ORIG-GUID: qeP1NaWcn2PUaWeJuCb5w_ZpUt_twXCJ X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-0031df01.pphosted.com id 453A7GpZ027645 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, 03 Jun 2024 09:47:26 -0700 Resent-From: quic_llindhol@quicinc.com Reply-To: devel@edk2.groups.io,quic_llindhol@quicinc.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: a2s7FznB4GcINw6aCoyGaLgSx7686176AA= Content-Language: en-GB Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=0iKuIdm2; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=quicinc.com (policy=none); 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 Marcin. A few high-level thoughs below. On 2024-05-31 08:14, Marcin Juszkiewicz wrote: > EDK2/ArmPkg/Library/ArmSmcLib has code to do SMC calls. >=20 > There are ArmCallSmc[0-3]() functions for up to 3 arguments/results and= =20 > ArmCallSmc() function which can use 7 arguments and get 4 results back. >=20 > This implementation looks like version B (Nov 2016) of SMCCC=20 > specification [1] with one more register used. >=20 > 1. https://developer.arm.com/documentation/den0028/b/ >=20 > In 2020 we got version C of spec (and then D, E, F) which allows to use= =20 > more registers: >=20 > > Allow R4=E2=80=94R7 (SMC32/HVC32) to be used as result registers. > > Allow X8=E2=80=94X17 to be used as parameter registers in SMC64/HVC64. > > Allow X4=E2=80=94X17 to be used as result registers in SMC64/HVC64. >=20 > And I started to wonder how to update EDK2 to newer version of SMCCC=20 > spec as one of in-progress QemuSbsa SMC calls may return more than 4=20 > values. Yes, definitely. This has been a wishlist item for some time, but in=20 reality we've only ever updated these when we needed new functionality. > ARM_SMC_ARGS in ArmSmcLib.h can be expanded to handle up to Arg17 in an= =20 > easy way and guarded by "#if defined(__aarch64__)" to not change it on=20 > Arm32. >=20 > Then ArmCallSmc() in {AArch64,Arm}/ArmSmc.S needs changes. But here it=20 > gets tricky. >=20 > On Arm we preserve r4-r8 and restore them after call like spec says.=20 > Which we do not do on AArch64 as version B of spec did not required that= =20 > (and this changed in version C). >=20 > If we start handling more than 4 results then we need to know how many=20 > results are expected and restore rest of r4-r7/x4-x17 registers: Yeah, it feels like we may want to add a version field or/and number of=20 registers to save/restore to a new struct. And we should definitely=20 align Arm/AArch64 behaviour. > From what I saw in both edk2/ and edk2-platforms/ most of code uses=20 > ArmCallSmc() function with ARM_SMC_ARGS structure populared with=20 > arguments. ArmCallSmc[0-3]() are used by Smbios, Psci and QemuSbsa code= =20 > only. The ArmCallSmc[0-3] helpers were only added as shorthand for most common=20 cases. I don't think we should worry about how those work for making any=20 design decisions. Everything they do can be described by the main=20 ArmCallSmc functions and a few lines of struct stuffing. > Now the question is: how to handle change? It could be that it would be easiest to add a new call function, and=20 maybe even ra new egister struct, than trying to adapt the existing ones=20 in ways that doesn't break existing users? That is if we care about existing users. We could always modify it to=20 guarantee breakage and expect users to update their code. Since this is=20 a library, and not a protocol, we *mostly* don't need to worry about=20 users mixing prebuilt binaries using old structs with new functions. > We could add ArmCallSmc[4-17] but that name only tells how many=20 > arguments we pass to SMC call, not how many results we expect. Or should= =20 > we add NumberOfResults argument to ArmCallSmc() to know which registers= =20 > we should preserve and which are results? And how complicated this=20 > assembly function will become? I don't think the assembly function needs to be that complicated. It'd=20 be a bit tedious with a bunch of tests, but... / Leif -=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 (#119431): https://edk2.groups.io/g/devel/message/119431 Mute This Topic: https://groups.io/mt/106403741/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-