Re: [PATCH 2/5] ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Mon, 26 Nov 2018 at 18:46, Leif Lindholm <leif.lindholm@linaro.org> 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.