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

[Laszlo Ersek <lersek@redhat.com>]

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?

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'd like to be sure that I understand this right, before starting my v2
review.

Thanks!
Laszlo