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

[Laszlo Ersek <lersek@redhat.com>]

On 11/27/18 13:13, Ard Biesheuvel wrote:
> 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.

And that's an excellent observation too; I should have noticed the
parallel with at least IA32 myself!

I remember the article where Brian explains why vendors ship IA32-only
firmware on 64-bit capable Intel processors. Hm... It's here:

https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems

Obviously Linux people were never happy with that, so they worked around
it, and the kernel switches to 64-bit mode itself, AFAIK... But what
about the RAM that the 32-bit DXE phase (and firmware runtime) can't
see, but the OS can? Maybe Linux can provide some pointers here (as you
say).

[...]

Thank you!
Laszlo