From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web10.3985.1648619947670599034 for ; Tue, 29 Mar 2022 22:59:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=llu52H+K; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: dovmurik@linux.ibm.com) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22U56WpE027979; Wed, 30 Mar 2022 05:59:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=+7wlgvz5yVxXZ1Zt1HauTtujjZZmdDpUSx+lV0sgUrY=; b=llu52H+KwUkKRJ3wWwW+isPBl4gnoK7TSO0OISaDht4Uys+nKkNLsuvEysiZqimEL3tB hPkaFH3NIbtfHjdYqNB39sPWMkFTPSEG91tD69i4gZCCDqQlTz2R3ZrqJTZJIskwdiJZ qUm45xJUW4INK4gJ8T7VxpoVhV40EVmwRN0hjy3JqoqnErHCyTwStBQRw3G+KBF8fB7A TUfCDZe794eypGlYrTvD6dhNZthjDsYLR39fFaQGnuW1DJ1OfdcRLlbXESCROe1r/QCP ZB7KhtYbyg31Tl2lJuWh/8Phw5vC3wVDFrWWvFcWcKdJ50kaondVAzddazPQIe1tbcWO rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3f409s5qc7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 05:59:05 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 22U5sMxg020290; Wed, 30 Mar 2022 05:59:04 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 3f409s5qby-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 05:59:04 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 22U5dTob032473; Wed, 30 Mar 2022 05:59:03 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma01dal.us.ibm.com with ESMTP id 3f1tfa1nk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 05:59:03 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22U5x2tl21889338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Mar 2022 05:59:02 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 81704112069; Wed, 30 Mar 2022 05:59:02 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3B45B112064; Wed, 30 Mar 2022 05:59:00 +0000 (GMT) Received: from [9.160.79.229] (unknown [9.160.79.229]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 30 Mar 2022 05:59:00 +0000 (GMT) Message-ID: <0f0cd090-ab5f-a8f6-d82d-56e459efae1c@linux.ibm.com> Date: Wed, 30 Mar 2022 08:58:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 1/2] OvmfPkg/AmdSev: Reorder MEMFD pages to match the order in OvmfPkgX64.fdf To: Gerd Hoffmann Cc: devel@edk2.groups.io, Ard Biesheuvel , Jiewen Yao , Jordan Justen , Brijesh Singh , Erdem Aktas , James Bottomley , Min Xu , Tom Lendacky , Tobin Feldman-Fitzthum References: <20220328184530.86797-1-dovmurik@linux.ibm.com> <20220328184530.86797-2-dovmurik@linux.ibm.com> <20220329113610.cbbj3iigjimnsska@sirius.home.kraxel.org> <97d772ff-d247-cd08-a08f-b9e0137b63fe@linux.ibm.com> <20220330051423.2n5o4odfwlz2ja2y@sirius.home.kraxel.org> From: "Dov Murik" In-Reply-To: <20220330051423.2n5o4odfwlz2ja2y@sirius.home.kraxel.org> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BfZuQcjmIj9Ut2rLqGP9-cRxgZ1g2qF1 X-Proofpoint-ORIG-GUID: lmWrKfl0kYjlv4JVJRq6qB-rsOaC8cvn X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-29_10,2022-03-29_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=999 clxscore=1015 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203300027 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30/03/2022 8:14, Gerd Hoffmann wrote: > On Tue, Mar 29, 2022 at 03:32:36PM +0300, Dov Murik wrote: >> Thanks Gerd for reviewing. >> >> On 29/03/2022 14:36, Gerd Hoffmann wrote: >>> On Mon, Mar 28, 2022 at 06:45:29PM +0000, Dov Murik wrote: >>>> Reorder the pages in the MEMFD section of AmdSevX64.fdf so that it >>>> matches the same order used in OvmfPkgX64.fdf. >>> >>> Makes sense. >>> >>> Acked-by: Gerd Hoffmann >> >> Thanks. >> >>> >>> Maybe also move this to a common include file, so it is less likely that >>> they run out of sync again? >>> >> >> I was contemplating that, but wasn't sure (I only use OvmfPkgX64 and >> AmdSevX64 in my testing). >> >> Is it common in edk2? > > We already have a few: > > kraxel@sirius ~/projects/edk2 (gcc12)# ls OvmfPkg/*.fdf.inc > OvmfPkg/FvmainCompactScratchEnd.fdf.inc OvmfPkg/OvmfTpmDxe.fdf.inc OvmfPkg/VarStore.fdf.inc > OvmfPkg/OvmfPkgDefines.fdf.inc OvmfPkg/OvmfTpmPei.fdf.inc OvmfPkg/XenElfHeader.fdf.inc > I saw these, but saw no !include directives in MEMFD areas, which are more sensitive because the addresses and sizes must match the surrounding definitions (unlike a list of INF directive like in NetworkPkg/Network.fdf.inc or general settings like in OvmfPkg/OvmfPkgDefines.fdf.inc). >> Would it apply to other OvmfPkg targets? I see similar MEMFD in >> CloudHvX64.fdf . > > I'd create one for the confidential computing memory areas, > that would only affect the builds which support SEV (and soon TDX). > Almost all the MEMFD entries are somehow related to confidential computing, isn't that the case? For example PcdOvmfWorkAreaBase -- I see it appears in the *.fdf of almost all targets. I want to reduce duplication (= extract common parts to an .inc file), but wonder what would be a clear and safe way to do it. Suggestions: Option 1: Extract all the MEMFD entries starting from: 0x000000|0x006000 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize up to (including): 0x00E000|0x001000 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize into OvmfMemFdPart1.fdf.inc, and !include it in OvmfPkgX64 and AmdSevX64. Option 2: Extract entire MEMFD part from OvmfPkgX64.fdf into OvmfMemFd.fdf.inc. In the middle of it add something like: !if $(SEV_LAUNCH_SECRET_ENABLE) == TRUE 0x00F000|0x000C00 gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize 0x00FC00|0x000400 gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize !endif and set that DEFINE in AmdSevX64.fdf only. > Not sure about CloudHvX64.fdf, as far I know it does not support > SEV/TDX, maybe those antries are only there because they have been > copied over from OvmfPkgX64.fdf The TDX series ("[PATCH V12 00/47] Enable Intel TDX in OvmfPkg (Config-A)") modifies CloudHvX64.*, and also the CloudHv/README mentions TDX. So I assume they intend to support it. -Dov