On Tue, 9 May 2023 at 19:24, Pedro Falcato <pedro.falc...@gmail.com> wrote: > > Hi all, > > (+CC people vaguely related to the EFI spec, the PML5 implementation > and kernel EFI boot code) > > As a result of the latest 5-level paging patches, I've been looking > into how tiano supports PML5. > This raised a question: Doesn't enabling PML5 in-firmware break > compatibility with non-PML5-aware bootloaders and kernels? > > From an architectural point of view: > - PML5 is enabled in CR4.LA57, but may only be toggled when not in > IA32e mode (so, only in 32-bit) > - Trying to mindlessly write to CR4 will #GP, and loading a 4-level > page tables will crash with probable page faults or #GPs > > From an EFI spec point of view: > - Whereas other architectures (arm64 for instance) specify the MMU > state in detail, the x64 bits do not specify anything beyond "Paging > enabled" (see 2.3.4). Which pre-PML5, was obviously well defined.
We actually have a related problem on ARM: the size of the virtual address space is not mandated by the spec, but it does require that all memory is mapped 1:1. This means that, if a system has any memory that is outside of the 48-bit physical range, it must enable 5 level paging to map it 1:1 in the 52-bit virtual range. Given that EDK2's page allocator allocates from top down from the end of the address space, we might end up with allocations for ACPI tables etc that cannot be mapped by kernels that do not implement support for 5 level paging. I imagine a similar issue might exist on x86 as well, and this suggests that using 5 level paging in the firmware is only sensible if it is guaranteed that the OS and loader can deal with it (IOW, running the firmware with 5 level pages and switching back to 4 in ExitBootServices() may result in other issues) > - When under boot services, this is likely not a problem as page > tables are owned by boot services. Unless they touch them as defined > in "2.3.4.3. Enabling Paging or Alternate Translations in an > Application", which may run into problems. > > From an OS kernel/bootloader point of view: > - A PML5 aware kernel/bootloader will likely correctly identify the > PML5 capability and enable LA57, load 5-level page tables. As such, > this scenario always works. > - A non-PML5-aware one may incorrectly overwrite LA57 (and #GP), or > just load a 4-level paging structure into CR3, and thus disastrously > crash. > > So, how is any of this supposed to work? > I don't think the firmware should ever use 5 level paging unless it is strictly needed for a particular use case. And even then, it should avoid allocating memory from the region that is only 1:1 accessible when 5 level paging is enabled. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104536): https://edk2.groups.io/g/devel/message/104536 Mute This Topic: https://groups.io/mt/98788948/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
