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. > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
