Re: [PATCH V6 1/1] OvmfPkg: Enable TDX in ResetVector

["Min Xu" <min.m.xu@intel.com>]

On September 21, 2021 1:16 PM, Gerd Hoffmann wrote:
> > +
> gUefiCpuPkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0|UINT64
> > + |0
> > + x60000017
> 
> > +typedef enum {
> > +  /* The guest is running with memory encryption disabled. */
> > +  CCAttrNotEncrypted = 0,
> > +
> > +  /* The guest is running with AMD SEV memory encryption enabled. */
> > +  CCAttrAmdSev      = 0x100,
> > +  CCAttrAmdSevEs    = 0x101,
> > +  CCAttrAmdSevSnp   = 0x102,
> > +
> > +  /* The guest is running with Intel TDX memory encryption enabled. */
> > +  CCAttrIntelTdx    = 0x200,
> > +} CONFIDENTIAL_COMPUTING_GUEST_ATTR;
> 
> > ConfidentialComputingGuestAttr is a 64-bit PCD, the byte[1] indicates the
> Guest type, byte[0] seems the sub type of the guest.
> >
> > And in the current definition of
> CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER:
> > typedef struct _CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER {
> >    UINT8                   GuestType;
> >   UINT8                   Reserved1[3];
> > } CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER;
> > Byte[0] is the Guest type.
> >
> > I am not sure what you mean:
> > > we should use the same approach (and the same enum) we are planing
> > > to use for the ConfidentialComputing PCD (see discussion in the other
> patch series).
> >
> > Shall we update CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER so that
> byte[0] is sub type, and byte[1] indicates the Guest type?
> 
> The idea is to make GuestType larger (UINT16 is probably enough), then use
> the CONFIDENTIAL_COMPUTING_GUEST_ATTR enum for GuestType too, so we
> don't have two different confidential computing guest type enumeration
> systems in edk2.
> 
> So, yes, effectively that would make byte[1] the type (sev/tdx/none) and
> byte[0] the sub-type thanks to little endian byte ordering.
>
I see. But such change may impact the existing SEV code in SecMain.c. Maybe there are more existing codes impacted.
I will not change the definition of CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER this time. Maybe in the future this change is needed.
> 
Thanks!
Min