On Wed, May 10, 2023 at 10:41 AM Ard Biesheuvel <a...@kernel.org> wrote: > > 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. >
Yes, your ARM problem sounds similar, but you do have the advantage that T0SZ (et al) have been there since forever, while for x86_64 this is just a surprise CR4 bit that you had no idea existed for the past 20 years. > 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. Do we need to have all the memory mapped? I know the EFI spec demands identity mapping, but it does sound a lot like we could reserve everything from 2^(va_size) onwards with some (new or old) EFI memory type and keep going? Right? I imagine 128/256 TiB of DRAM will work just fine for EFI firmware... Basically, EFI allocations and usage would be restricted to commonly accessible ranges of memory (47-bit for x86, 48 for ARM64, etc...) > > 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) > Right. Sadly, I don't think you can even pull an EBS() trick here, as in theory you *can* set up alternate translations, even when under boot services (see 2.3.4.3). > > - 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. I agree. But I would like it if the more EFI "big whigs" (Mike K, Andrew, etc) could give a heads up as to what should happen. And then possibly put wording into the spec. -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104593): https://edk2.groups.io/g/devel/message/104593 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] -=-=-=-=-=-=-=-=-=-=-=-
