> + 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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80923): https://edk2.groups.io/g/devel/message/80923
Mute This Topic: https://groups.io/mt/85597386/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
