Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

["Yao, Jiewen" <jiewen.yao@intel.com>]

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.xu@intel.com>
> Cc: Brijesh Singh <brijesh.singh@amd.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; devel@edk2.groups.io; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@intel.com>;
> Erdem Aktas <erdemaktas@google.com>; James Bottomley
> <jejb@linux.ibm.com>; Tom Lendacky <thomas.lendacky@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
> 
> 
> 
> 
>