Re: [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit

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

On Tue, 27 Nov 2018 at 13:11, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 11/26/18 23:37, Ard Biesheuvel wrote:
> > The ArmVirtQemu targets currently limit the size of the IPA space to
> > 40 bits because that is all what KVM supports. However, this is about
> > to change, and so we need to update the code if we want to ensure that
> > our UEFI firmware builds can keep running on systems that set values
> > other than 40 (which could be > 40 or < 40)
> >
> > So refactor the way we deal with this limit, both for bare metal and for
> > virtual targets, so that
> > a) the range of the GCD memory map is based directly on the CPU's PA range
> > b) the range of the 1:1 mapping in the page tables is based on the CPU's PA
> >    range (unless it exceeds what the architecture permits for 4k pages)
> > c) PcdPrePiCpuMemorySize is no longer needed, and can be removed.
> >
> > Patch #1 introduces ARM_MMU_IDMAP_RANGE and ArmGetPhysicalAddressBits ()
> > in ArmLib.
>
> OK, so the crucial piece of info I missed under v1 was that given the
> fixed 4KB page size under UEFI, we might not be able to identity map all
> the memory that the CPU would otherwise be capable of addressing
> (assuming the OS set up a larger page size).
>
> However... that seems to leave us with a conundrum. (I'm 100% sure it is
> nothing new to you, but it is new to me.)
>
> If we size the GCD memory space map exactly to what we can identity map
> under UEFI, then the UEFI memmap will not advertize the rest of the RAM
> to the OS, and the memory will be unusable.
>
> On the other hand, if we size the GCD to the exact RAM size (part of
> which could be out of reach for the CPU *under UEFI*, using 4KB pages),
> then the OS will be happy. But, what happens when gBS->AllocatePages()
> is served from such a high (>48bits) address range, and then the client
> module tries to access the (not mapped) chunk?
>

That is an excellent question, given that IA32 and ARM are in exactly
the same boat with [L]PAE.

> Hm... Actually, once this becomes a practical problem, I think we can
> take care of it, in a platform PEIM. Namely, just pre-allocate the
> entire inaccessible / unmappable range (beyond 48-bits) as Boot Services
> Data type memory. That will keep the rest of the firmware out (no
> well-behaving module will read or write memory that it didn't allocate),
> and the OS will be happy to release and reuse that memory.
>
> Does this make sense?
>

I will look into how IA32 and ARM deal with this at the moment. Well spotted!

> I'd like to be sure that I understand this right, before starting my v2
> review.
>
> Thanks!
> Laszlo