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

["Gerd Hoffmann" <kraxel@redhat.com>]

  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