On Mon, 26 Nov 2018 at 18:46, Leif Lindholm <[email protected]> wrote: > > On Fri, Nov 23, 2018 at 01:14:28PM +0100, Ard Biesheuvel wrote: > > In preparation of permitting the virt code to define a larger PA space > > size via gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize than what the > > CPU actually supports, take the CPU's capabilities into account when > > setting up the page tables. This is necessary because KVM will shortly > > support variable PA space sizes, and to support running the same UEFI > > binaries regardless of that limit, PcdPrePiCpuMemorySize needs to be > > treated as an upper bound rather than a fixed size. > > Why do we keep PcdPrePiCpuMemorySize at all? (I.e., rather than just > using the probed value? > Mainly for the purpose of being able to restrict ourselves to 32/48 > bits? > > If we keep it, should we rename > PcdPrePiCpuMemorySize -> PcdPrePiCpuMemoryBits > and > PcdPrePiCpuIoSize -> PcdPrePiCpuIoBits > ? > > Argument against this would be that later consumers still refer to > the value extracted from the HOB as SizeOf*Space, and happily shifts > 1s around by it :| >
I am reworking this so PcdPrePiCpuMemorySize retains its meaning. Instead, I will add something like this to ArmLib.h // // ARM_MMU_IDMAP_LIMIT defines the maximum size of the identity mapping // that covers the entire address space when running in UEFI. This is limited // to what can architecturally be mapped using a 4 KB granule, even if the // hardware is capable of mapping more using larger pages. // #ifdef MDE_CPU_ARM #define ARM_MMU_IDMAP_LIMIT (MAX_UINT32) #else #define ARM_MMU_IDMAP_LIMIT (1ULL << 48) #endif and use that in the MMU code as an upper bound in case the CPU supports 52 bits. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
