I think both are correct. The dump info is from a *client* machine in old generation - kabylake. 39 bits physical is good enough.
GPAW in TD is enforced by TDX-module. Please refer to https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-module-1.0-public-spec-v0.931.pdf, Section 10.1.2, Table 10.1 - RBX[5:0] is GPAW - only 48 and 52 are possible. Thank you Yao Jiewen > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd > Hoffmann > Sent: Wednesday, February 23, 2022 6:07 PM > To: Xu, Min M <min.m...@intel.com> > Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianoc...@kernel.org>; Justen, > Jordan L <jordan.l.jus...@intel.com>; Brijesh Singh <brijesh.si...@amd.com>; > Aktas, Erdem <erdemak...@google.com>; James Bottomley > <j...@linux.ibm.com>; Yao, Jiewen <jiewen....@intel.com>; Tom Lendacky > <thomas.lenda...@amd.com> > Subject: Re: [edk2-devel] [PATCH V6 33/42] OvmfPkg: Update PlatformInitLib > for Tdx guest to publish ram regions > > Hi, > > > Another update is in PlatformAddressWidthInitialization. The physical > > address width that Tdx guest supports is either 48 or 52. > > Hmm. Sure this is correct? > > 48 is the max _virtual_ address space possible with 4-level paging. > The _physical_ address space might be much smaller, like this > (kaby lake desktop system): > > # lscpu > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Address sizes: 39 bits physical, 48 bits virtual > Byte Order: Little Endian > > Maybe all TDX-capable Intel CPUs actually have >= 48 bits physical, > so this could be fine, but please double-check. > > thanks, > Gerd > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#86893): https://edk2.groups.io/g/devel/message/86893 Mute This Topic: https://groups.io/mt/89252063/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
