In SmmMemLib there's a routine to determine the maximum physical address
supported by a processor:
//
// Get physical address bits supported.
//
Hob = GetFirstHob (EFI_HOB_TYPE_CPU);
if (Hob != NULL) {
PhysicalAddressBits = ((EFI_HOB_CPU *) Hob)->SizeOfMemorySpace;
} else {
AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
if (RegEax >= 0x80000008) {
AsmCpuid (0x80000008, &RegEax, NULL, NULL, NULL);
PhysicalAddressBits = (UINT8) RegEax;
} else {
PhysicalAddressBits = 36;
}
}
This is problematic in a couple ways:
1. AsmCpuid is not portable across architectures (understandably we would have
said that SMM is an IA thing originally)
2. The PI spec for SMM does not specify the use of HOBs (in fact I was very
surprised to even see HOBs in SMM, and even more confounded by platforms using
the "DxeHobLib" in the SMM core and drivers!)
I think this would be a good job for a base library interface to handle - (e.g.
UINTN GetCpuPhysicalAddressBits(). You could then have a version that uses
HOBs (MdePkg), another IA specific one (UefiCpuPackage) that uses CPU ID, and
one that works for ARM (ArmPkg) that reads ID registers.
Does that sound reasonable?
[Presumably this is just the beginning - we see AsmCpuId show up in a lot of
modules that need to be architecture-agnostic like BootScript (1G page
support), CapsulePei (1G page support), and AcpiS3SaveDxe (1G pages and
physical address size).]
Eugene
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
