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

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

> + 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.

take care,
  Gerd