Message ID | 20181126223801.17121-1-ard.biesheuvel@linaro.org |
---|---|
Headers | show |
Series | ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit | expand |
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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel