From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (NAM11-DM6-obe.outbound.protection.outlook.com [40.107.223.46]) by mx.groups.io with SMTP id smtpd.web12.5003.1632405827149993603 for ; Thu, 23 Sep 2021 07:03:47 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amd.com header.s=selector1 header.b=AviDI9E0; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.223.46, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kq810gVtCxypYHEWNG6cq2rppv5tkz9zqUruVjrbKor6ik37io11G11BneBtgbtxsbxm7jiYKYkzi7O0ySQ4Hpf9g0p06+fqXEV9K4hmOzKMxpFjnEL/3ViutcJpq49WzIEk5Wkx0jTaaoG0+110wOZlgQnUCpLC4LWib+jN2T4zaQhLS6phhCvbIX+wjBMuEbkWEN/APVgCWUkOYeTVHlp+Wk2rq/WHBHYS1Zv4Go3K20J97V8cXklZBZvDMIKbrUm5ZKgHi2qiU9hx9fT8AsdB6kvuC59GCPMcFBc9LrIY709xdkQDiwAFEJ5kuP/G+oirnFCOnujFZI6ZMscgCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=74suoUBSjCtOkeEacZOfWbvAX1unS3j6quLywFYB/Aw=; b=hr8ErjbiaU0hEuxmQrB6471O67GJmubhqFlTay79K06TFN8U0htTt6PJwuLpF9CdTiZ/UxOzHkUWBG6z36fVuaQ1eCuT0sI2zU0m+5jXTws7UyCC8z0prsiiHkpa9rGoA+fipwcfWMpJKzQupLGugYBx/Dn1JfpOkelswpUTRdP7Yfxi5JgOaUtBEmgayZOXhoAEXGY0ubbgcAXMgJGy/55pxCY/piLK82RtyOKy2L95/SN9JgUnxglgBDvE5+9IG5hOi5WYOUFzBSAN5rTuLAuKlv9ioHdtiKf/fjxV3cuA/o5guiECmw9jTZupcR24aQXxVWHP0Io7YD5lJC7L+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=74suoUBSjCtOkeEacZOfWbvAX1unS3j6quLywFYB/Aw=; b=AviDI9E0K9Nfsx18E8qxnqaEO9w0Cd4JabaadCp4EItUt8HBlcXRG0s/J7XWxUboDYoCRH/SAOLfkjpv0zN5Jzw7Ejro0eXMdlKUqFKtyvcxxAO4Ed0vcUuuYHfcfOMkBw2HN1EKKlG0CP9s0njE8vKFj8ujgNuXlJDNWcAgq5A= Authentication-Results: amd.com; dkim=none (message not signed) header.d=none;amd.com; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SN1PR12MB2368.namprd12.prod.outlook.com (2603:10b6:802:32::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13; Thu, 23 Sep 2021 14:03:43 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::78b7:7336:d363:9be3]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::78b7:7336:d363:9be3%6]) with mapi id 15.20.4523.022; Thu, 23 Sep 2021 14:03:43 +0000 CC: brijesh.singh@amd.com, Ard Biesheuvel , "Justen, Jordan L" , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector To: "Yao, Jiewen" , "Xu, Min M" , "devel@edk2.groups.io" , Gerd Hoffmann References: <12721dade1f2f9905cc34271d9abec24650442ff.1632214561.git.min.m.xu@intel.com> <20210922074929.e5iwf24t6wyndgbu@sirius.home.kraxel.org> <20210923084821.yxizus3loa2p6hms@sirius.home.kraxel.org> <7c9aeb95-5c33-bd8d-4f0c-40133f4c7c3d@amd.com> From: "Brijesh Singh" Message-ID: Date: Thu, 23 Sep 2021 09:03:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: X-ClientProxiedBy: SA9PR13CA0078.namprd13.prod.outlook.com (2603:10b6:806:23::23) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) Return-Path: brijesh.singh@amd.com MIME-Version: 1.0 Received: from [10.236.30.107] (165.204.77.1) by SA9PR13CA0078.namprd13.prod.outlook.com (2603:10b6:806:23::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.8 via Frontend Transport; Thu, 23 Sep 2021 14:03:43 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 474c6a99-b1f1-49ec-b75c-08d97e9af3f6 X-MS-TrafficTypeDiagnostic: SN1PR12MB2368: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I2HA0PiUquCVQSD5/sfoIcNU9e0gd1lV/0Edyq+V3vBpU/95t3qPB+n95s7ctWtQgqJABV9JpQ6vzmndvI+nI7FLt5OAT4QAhjsyojYfIRpVCSYttDc0x/CRvMKfZlXTTgCOzcsCLuux4rFLPHXY2DziAlCUC//eUpFf/ANF+eBCzMmZgxjcgGHvGsw+eTLaHIO+P7H/4DU5RfEkgClmb2+/wAEqp9QTiPdlA/zJ1x3V+lLsKJnK5SLwMPOzSE5xQpBvSOBxy2J3ch/LukhRHxvsSg5ydUDOQg7h0sk7w1D51QpbYtLIVLOyy/Y/UQtPCpBuXvHKogxywWhaNBqbDSJzcEKTCWrJxyLsBsjc0MryhTmk5FOSOB9BpPGJAawa3n++67c3F0FhPK6co6CCBni3F3k0/JhLaZkYztbF+bGSfrmbxLQXI3W7UOkYsW9zYlGos1TumGnUStqvT4q6FNorzwrmZMX9DpFP2z28RARUrafU6b/LfeqmdL6oBS57ahxy7pgzNXzRLevy+ZPnE2ccrXDzBu44a0CJePEjckUTUKZp+Dz8r12F2psfOseRdv/jBXjn88hUSpv0wSJYcwaQripUxAIrVItKWauy9l3CBVyWwX0o6qA9ffuj4O/Yqo2gPVgYEtKWXTKU6NXmql+KIUUjf820hcwlF3O20+DcIapJ2W1gOq+U9UKwsx92yFaHHz2JyM9q+jgbhlx4tiUq+zgbXkOgkghkMqIeSbPHMFOI25Gz01LGddXE5E3uStYUdmyDz2cy/2B2g8tHIv0+UdvYQRkaArXOZChe8DOxz5NhwSRXHbUMxHfSDcKq03E+P78XibAJ5Q8AdoZjvxlBoymgbD+QVCAnHrjne4HZkfoxK9HCW1lDrVJecjG9cfQRtFl+dq/igE0chtb5btKVPGWMJpWWdsXXWOS3qHY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR12MB2718.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(66476007)(2906002)(52116002)(66556008)(8936002)(8676002)(508600001)(44832011)(45080400002)(5660300002)(38350700002)(186003)(966005)(30864003)(38100700002)(31686004)(86362001)(16576012)(53546011)(316002)(31696002)(83380400001)(66946007)(4326008)(956004)(36756003)(6486002)(26005)(54906003)(2616005)(110136005)(21314003)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ueFMSBpb4xt2Zspe0nupoED9xnkCajUpKrkupYJMcr3ju31ReXuacSQmV9fp?= =?us-ascii?Q?FE5hDSYnRzbA4WAvSkUxeUtzz2qKos9UkfI8SFYREOiMjVwYbS0Ryl1LH7dU?= =?us-ascii?Q?FAfWZIvwyPtN0kgL1knfbpdr3lL1Ih0i/Kh7b/OAJLnypRysJ0hgAaadbYFP?= =?us-ascii?Q?xbSITr2I5pZZrRdr1UiIwfmOnHUoMRStWoh/54G/xHoyzepL4VGePvbnVZ7o?= =?us-ascii?Q?jxaflyfcoq4a/+ZoyreFzo/iNt0xWWYLowybPIBBulaKTpeRV+8K0cchk/LN?= =?us-ascii?Q?OZCdUzHwZjJjorihlXBe2vDxB82MJOvOXkpDxSaEX/R0cWJz1J2vKjk0vlZq?= =?us-ascii?Q?U9F35rfj34RqT3XeU6lgVQl6GO4OmN1qkEUdidzYAxQja92nBxPzEkvLSA5D?= =?us-ascii?Q?ROJPAo7a/140p0fyuyrkHm2tkD+uyyO3FcurLJymvhPRiM9hr9TUupfAAvJ/?= =?us-ascii?Q?xDIiVAAPHuqJmTg/B+C3B/WmZM9PremOnh/Eint4uBWp9HwYHCgFYINqg7aw?= =?us-ascii?Q?Kqb0zEHMG38h6wcA/Qle+EiLN90PHI9YSJU0R175x6IB+KHBF1QrPQCuk00q?= =?us-ascii?Q?vukgFoHohK/eCtQUlCqgYFblF8D6LOlFl8XYk4JFkR3B4PrgEKlhambXffKc?= =?us-ascii?Q?9OCOixbEDhF+6g1T5KyU1fm44Izv6TL2xO7CaMB+X/UtUVDVoLw5M/fvnXqt?= =?us-ascii?Q?U/y344Ah8FB4GQGfi41zrgJ04xhNvy0Hx0VWWgrJG1fyXFQJrfW9SCckW8rD?= =?us-ascii?Q?4ENs5W2nQMYjfE6y2tGWBP65F1nWMBbTf2UegUd+bNUhoGu+oVzWclC1fhvZ?= =?us-ascii?Q?A2jUQ+Nab5bYE6j0NRFJJWnfgrPL+rIUSyVu+d6k5Ulw9XlkZcdibSWfditp?= =?us-ascii?Q?JrNlmSkxcShXWJKMJeC7Pg0Y6ZcbT7yhoM4+zJ8mlch0sa6JaR7xfS+CRiJk?= =?us-ascii?Q?ucF7Ca5F7SkBlccAor023wQ+b8MqHzisbSDjw19/VfX1vr+q/TYL3qL8VMe2?= =?us-ascii?Q?2+V/yz5dJwJTLdf52nOrdG9X6QfR2jozKiscFgL4MJNCYZZ7Efm7aCFyPX5X?= =?us-ascii?Q?2pxKXQF/ReinmCi2Eb+ftt1qOLJIkXn4oiInsXWszx1II4a4qxvJKdxUBgC2?= =?us-ascii?Q?EOeZugUAzwmCi145wPuDd1EMKzDeQ7ExIBff9S4P9BFPUkLTWW1Th19UO+QK?= =?us-ascii?Q?h+cG9Q974IqLrosOyB0eGZrS4IEEt44I/gy87zp3oIjgu27BHaMOZLedmIxo?= =?us-ascii?Q?tsTmTfFKPwQX+CPWx+7nvweiuMHDwmTIsXwJiG+7l5AKCUjlRhgrZnLUWfQ1?= =?us-ascii?Q?eDdRFjbB6UNubZ4ggHwFEViT?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 474c6a99-b1f1-49ec-b75c-08d97e9af3f6 X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2021 14:03:43.5959 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QJOGpULm3qDsuLOn5XxvcV7KcaStv6oDnYci1qGqNeGPaLC0IvL/9DbBlwyjZuppAY1g1j4YD2GDADJFThU6BQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB2368 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable SEV hardware does not have a concept of the metadata. To boot SEV guest=20 we need to pass some information to VMM and in past those information=20 were passed through SNP_BOOT_BLOCK (GUIDed structure) but Gerd=20 recommended that it will be good idea if both SEV and TDX uses a common=20 metadata approach to pass these information. I personally think it was a=20 good suggestion. So, in SNP series I went ahead and created a generic=20 metadata structure and hope that TDX will build on it. The user of the=20 metadata structure is VMM (qemu, etc); while launching the guest the VMM=20 knows whether its creating the SEV or TDX guest and will process the=20 entries accordingly. As per the number of fields in the metadata is concerns, I felt 3 fields=20 (start, size and type) should be good enough for all the cases. There=20 was a question from Gerd to Min asking why do you need the=20 dataoffset/rawdatasize etc and I don't remember seeing the answer for=20 it. As I said in the start, SNP hardware does not enforce metadata=20 layout so I am flexible to add more field or remove or keep it separate. thanks On 9/23/21 8:38 AM, Yao, Jiewen wrote: > Good point, Min. >=20 > If https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= thub.com%2FAMDESE%2Fovmf%2Fblob%2Fsnp-v8%2FOvmfPkg%2FResetVector%2FX64%2FOv= mfMetadata.asm&data=3D04%7C01%7Cbrijesh.singh%40amd.com%7C52f6327efa334= 80bf4a308d97e977ff0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6376800114= 16117826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi= I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DzDfikRYhxd8ERY%2Fw6kJLhJKRNWbYT= l4D6PpqK%2BVNsus%3D&reserved=3D0 is the proposal, then I have more comm= ent: >=20 > Type: OVMF_SECTION_TYPE_CODE, OVMF_SECTION_TYPE_VARS are NOT used for SEV= . I am not sure why they are there. >=20 > Type: OVMF_SECTION_TYPE_CPUID should be SEV specific. TDX does not need C= PUID page. >=20 > Type: OVMF_SECTION_TYPE_SEC_MEM also seems for SEV. TDX does not need thi= s special memory, such as Page table. It is already covered by code. >=20 > Type: OVMF_SECTION_TYPE_SNP_SECRETS / OVMF_SECTION_TYPE_SNP_SEC_MEM is SE= V specific. >=20 > The SEV table is totally different with TDX metadata table. I really cann= ot see the benefit to merge into one table. >=20 > Thank you > Yao Jiewen >=20 >> -----Original Message----- >> From: Xu, Min M >> Sent: Thursday, September 23, 2021 9:20 PM >> To: devel@edk2.groups.io; brijesh.singh@amd.com; Yao, Jiewen >> ; Gerd Hoffmann >> Cc: Ard Biesheuvel ; Justen, Jordan L >> ; Erdem Aktas ; James >> Bottomley ; Tom Lendacky >> Subject: RE: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVec= tor >> >> I suggest SEV and TDX keep their own metadata in separate files. This is= because >> SEV and TDX has different item structure. >> >> From the OvmfMetadata definition in SEV >> (https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit= hub.com%2FAMDESE%2Fovmf%2Fblob%2Fsnp-&data=3D04%7C01%7Cbrijesh.singh%40= amd.com%7C52f6327efa33480bf4a308d97e977ff0%7C3dd8961fe4884e608e11a82d994e18= 3d%7C0%7C0%7C637680011416117826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA= iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Dat43H9sg= mlaD773wsU5%2BoPPSjImo0UiCxQ0nmwdV9ds%3D&reserved=3D0 >> v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm) there are 3 fields in the >> item. (Base/Size/Type). >> >> But for TDX, there are 6 fields >> (DataOffset/RawDataSize/MemoryAddress/MemorySize/Type/Attribute) in one >> item. >> That is because TDX-QEMU not only initialize the memory region, but also= does >> more tasks (measurement) if the Attribute indicates. >> DataOffset/RawDataSize is used by the TDX-QEMU to do the measurement if >> the Attribute field is MR.EXTEND. >> MemoryAddress/MemorySize indicates the TDX-QEMU how to initialize the >> memory region. >> >> We can add more fields in the item to make it workable for both SEV and = TDX, >> (for example, add DataOffset/RawDataSize/Attribute), but it also restric= t the >> changes in the future if more fields is needed (TDX's change will impact= the >> existing SEV-QEMU). >> >> On September 23, 2021 8:55 PM, Brijesh Singh wrote: >>> >>> Like Gerd I would prefer to have one metadata table in the reset GUID. >>> The metadata table will contain multiple entries; lot of entries are co= mmon >>> between SNP and TDX. Some entries will have specific meaning for the >> platform. >>> Those special entries should be marked using the >>> OVMF_SECTION_TYPE_{TDX,SNP}_XXXX. It is perfectly fine to have a more >> than >>> one entry for the same region with different type, e.g >>> >>> GhcbBookkeepingSnp: >>> >>> =C2=A0 GHCB_BOOKKEPING_BASE_ADDRESS >>> >>> =C2=A0 GHCB_BOOKKEEPING_SIZE >>> >>> =C2=A0 OVMF_SECTION_TYPE_SNP_MEM >>> >>> TdxMailBoxExt: >>> >>> =C2=A0 GHCB_BOOKKEPING_BASE_ADDRESS >>> >>> =C2=A0 GHCB_BOOKKEEPING_SIZE >>> >>> =C2=A0 OVMF_SECTION_TYPE_TDX_MAILBOX >>> >>> If we want all the OVMF_SECTION_TYPE_SNP_xxx should be defined in a >>> separate file then that is also doable. I put everything in one place b= ecause I >> was >>> trying to keep entry order similar to what is present in MEMFD. >>> >>> thanks >>> >>> On 9/23/21 6:39 AM, Yao, Jiewen wrote: >>>> I strongly recommend to separate SEV and TDX in all context, if it is >> something >>> SEV or TDX specific. >>>> Then each file has clear ownership. >>>> If it is something generic for both SEV and TDX, it can in one file. >>>> >>>> For example, SecPeiTempRam/SecPageTable can be in common file. >>>> But SevSnpSecrets/GhcbBookkeeping should be in SEV file. >>>> >>>> Thank you >>>> Yao Jiewen >>>> >>>>> -----Original Message----- >>>>> From: Gerd Hoffmann >>>>> Sent: Thursday, September 23, 2021 4:48 PM >>>>> To: Xu, Min M >>>>> Cc: devel@edk2.groups.io; Ard Biesheuvel ; >>>>> Justen, Jordan L ; Brijesh Singh >>>>> ; Erdem Aktas ; >> James >>>>> Bottomley ; Yao, Jiewen ; >>>>> Tom Lendacky >>>>> Subject: Re: [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector >>>>> >>>>> On Thu, Sep 23, 2021 at 12:38:24AM +0000, Xu, Min M wrote: >>>>>> On September 22, 2021 3:49 PM, Gerd Hoffmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> +%ifdef ARCH_X64 >>>>>>>> +; >>>>>>>> +; TDX Metadata offset block >>>>>>>> +; >>>>>>>> +; TdxMetadata.asm is included in ARCH_X64 because Inte TDX is >>>>>>>> +only ; available in ARCH_X64. Below block describes the offset of >>>>>>>> +; TdxMetadata block in Ovmf image ; ; GUID : >>>>>>>> +e47a6535-984a-4798-865e-4685a7bf8ec2 >>>>>>>> +; >>>>>>>> +tdxMetadataOffsetStart: >>>>>>>> + DD tdxMetadataOffsetStart - TdxMetadataGuid - 16 >>>>>>>> + DW tdxMetadataOffsetEnd - tdxMetadataOffsetStart >>>>>>>> + DB 0x35, 0x65, 0x7a, 0xe4, 0x4a, 0x98, 0x98, 0x47 >>>>>>>> + DB 0x86, 0x5e, 0x46, 0x85, 0xa7, 0xbf, 0x8e, 0xc2 >>>>>>>> +tdxMetadataOffsetEnd: >>>>>>>> + >>>>>>>> +%endif >>>>>>> This should be switched to common ovmf metadata (see patches 4-7 of >>>>>>> the SEV-SNP series). >>>>>>> >>>>>>> Min: please have a look at these patches. >>>>>>> >>>>>> Hi, Gerd >>>>>> I checked the patches 4-7 of the SEV-SNP series. The common >>>>>> OvmfMetadata is designed for both SEV and TDX, right? >>>>> That is the idea, yes. >>>>> >>>>>> If so, then it means the SEV and TDX metadata will be mixed in this >>>>>> OvmfMetadata. >>>>> Yes. >>>>> >>>>>> I am thinking there will always be different fields for SEV and TDX. >>>>>> For example, SEV has PcdOvmfSecGhcbPageTable but TDX doesn't need >>>>>> that page. If the common OvmfMetadata is consumed by TDX-QEMU, >> then >>>>>> PcdOvmfSecGhcbPageTableBase will be initialized too. >>>>>> That doesn't make sense. >>>>> We have different range types. OVMF_* are the common areas. SEV_* >>>>> will be used by sev only, TDX_* will be used by tdx only. TDX and >>>>> SEV entries are allowed to overlap, i.e. PcdOvmfSecGhcbPageTableBase >>>>> should have some SEV_* type for sev (I think this needs fixing in the >>>>> series), and tdx can use the page for something else by adding an >>>>> TDX_* entry for the same range. >>>>> >>>>>> I am thinking that SEV and TDX can keep their own Metadata (in >>>>>> separate files, SevMetadata.asm and TdxMetadata.asm) which are >>>>>> pointed by the SEV or TDX offsets in the GUID-ed chain in ResetVecto= r. >>>>> I'd very much prefer to have a single table to avoid duplication for >>>>> the common memory areas and keep the reset vector small. >>>>> >>>>> Having separate SevMetadata.asm + TdxMetadata.asm files (then have >>>>> OvmfMetadata.asm include these two) is an option. I think this isn't >>>>> needed, we can also just group the entries in OvmfMetadata.asm. >>>>> >>>>>> In this case, SEV and TDX can design their own metadata flexibly, >>>>>> for example, the attribute, the item structure, add/remove/update >>>>>> the items, etc. >>>>> Why have two ways to do the same thing? >>>>> >>>>> take care, >>>>> Gerd >>> >>> >>>=20 >>> >=20