On Thu, Sep 23, 2021 at 01:38:52PM +0000, Yao, Jiewen wrote: > Good point, Min. > > If > https://github.com/AMDESE/ovmf/blob/snp-v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm > is the proposal, then I have more comment: > > Type: OVMF_SECTION_TYPE_CODE, OVMF_SECTION_TYPE_VARS are NOT used for SEV. I > am not sure why they are there.
tdx needs them (for measurement). It's not a tdx-specific concept, possibly sev-snp wants use that too in the future. > Type: OVMF_SECTION_TYPE_CPUID should be SEV specific. TDX does not need CPUID > page. A cpuid page can be used without sev too. > Type: OVMF_SECTION_TYPE_SEC_MEM also seems for SEV. TDX does not need this > special memory, such as Page table. It is already covered by code. These are "needs pre-validation / pre-acceptance" regions. TDX surely needs that too. > Type: OVMF_SECTION_TYPE_SNP_SECRETS / OVMF_SECTION_TYPE_SNP_SEC_MEM is SEV > specific. Yes. > The SEV table is totally different with TDX metadata table. I can't see a fundamental difference. In both cases the VMM needs to know the firmware memory layout for (a) attestation, and (b) pre-validating/pre-acceptance of memory, and (c) some hardware-specific ranges such as snp secrets page. > I really cannot see the benefit to merge into one table. Keep reset vector small? Have common parser structs and code? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#81062): https://edk2.groups.io/g/devel/message/81062 Mute This Topic: https://groups.io/mt/85761661/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
