On 11/27/18 13:13, Ard Biesheuvel wrote: > On Tue, 27 Nov 2018 at 13:11, Laszlo Ersek <[email protected]> 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
