Hi Gerd Having config-a and config-b is proposed by original RedHat rep in EDKII - Laszlo. We reach the agreement to separate those 2 configuration and AMD SEV is taking same approach.
Are you saying you want to reset the high level plan and unify config-a and config-b into one binary? Thank you Yao Jiewen > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd > Hoffmann > Sent: Friday, September 24, 2021 1:28 PM > To: Xu, Min M <min.m...@intel.com> > Cc: Brijesh Singh <brijesh.si...@amd.com>; Yao, Jiewen > <jiewen....@intel.com>; devel@edk2.groups.io; Ard Biesheuvel > <ardb+tianoc...@kernel.org>; Justen, Jordan L <jordan.l.jus...@intel.com>; > Erdem Aktas <erdemak...@google.com>; James Bottomley > <j...@linux.ibm.com>; Tom Lendacky <thomas.lenda...@amd.com> > Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector > > Hi, > > > > SEV hardware does not have a concept of the metadata. To boot SEV guest > we > > > need to pass some information to VMM and in past those information were > > > passed through SNP_BOOT_BLOCK (GUIDed structure) but Gerd > recommended > > > that it will be good idea if both SEV and TDX uses a common metadata > approach > > > to pass these information. I personally think it was a good suggestion. > > > So, in > SNP > > > series I went ahead and created a generic metadata structure and hope > > > that > > > TDX will build on it. The user of the metadata structure is VMM (qemu, > > > etc); > > > while launching the guest the VMM knows whether its creating the SEV or > TDX > > > guest and will process the entries accordingly. > > > > > > As per the number of fields in the metadata is concerns, I felt 3 fields > > > (start, > size > > > and type) should be good enough for all the cases. There was a question > from > > > Gerd to Min asking why do you need the dataoffset/rawdatasize etc and I > don't > > > remember seeing the answer for it. > > > > The discussion is in this link. https://edk2.groups.io/g/devel/message/80289 > > The question why TDX_BFV_RAW_DATA_OFFSET and > TDX_BFV_RAW_DATA_SIZE are > needed and why TDX_BFV_MEMORY_BASE + TDX_BFV_MEMORY_SIZE can't be > used > is still open. > > While being at it: The question why "config-b" with a completely > different initialization code path is needed is still open too. The > tdvf design guide is not helpful here. Although explains what is > different in "config-a" vs. "config-b" it does not explain the > background, i.e. why some features are supported by "config-b" > only. > > And I guess these two questions are related. With "config-a" there is a > fixed offset between TDX_BFV_RAW_DATA_OFFSET + TDX_BFV_MEMORY_BASE, > so > if you know one of them you can easily calculate the other. With > "config-b" this is possibly not the case. > > So, can you please shed some light on this? > > thanks, > Gerd > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#81068): https://edk2.groups.io/g/devel/message/81068 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] -=-=-=-=-=-=-=-=-=-=-=-
