Re: [edk2-devel] Side effects of enabling PML5 in EFI

["Ni, Ray" <ray.ni@intel.com>]

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro
> Falcato
> Sent: Thursday, May 11, 2023 12:39 AM
> To: Ni, Ray <ray.ni@intel.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>; devel@edk2.groups.io; Andrew Fish
> <afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Ard
> Biesheuvel <ardb@kernel.org>
> Subject: Re: [edk2-devel] Side effects of enabling PML5 in EFI
> 
> On Wed, May 10, 2023 at 10:34 AM Ni, Ray <ray.ni@intel.com> wrote:
> >
> > Firmware chooses to use 5-level paging when the platform using this firmware
> claims to boot 5-level paging OS only.
> >
> > Usually, firmware uses 4-level paging to keep maximum OS compability.
> 
> Hi Ray,
> 
> So, what happens if I don't enable LA57, have a gazillion TB of memory
> (such that I go over the 128TB 47-bit AS limit). Will EFI never try to
> access memory up there and page fault?

No. UEFI firmware on x86 doesn't try to create non-1:1 mapping page table to let
firmware code access these high physical addresses.

> 
> What happens to the OS/bootloader? If it asks for memory up there (for
> KASLR, etc)? Does the memory map pre-reserve those upper regions of
> memory that are not accessible using 4-level paging?

That depends on how the EFI_HOB_CPU is produced from the firmware code.
The UEFI memory map data is from GCD database in DxeCore.
GCD database is built based on the physical address size value in EFI_HOB_CPU.

> 
> I really fail to see the advantages of PML5 support in EFI fw at the
> moment, particularly as you can simply choose to start all your
> allocations lower down the memory map (where you can indeed access
> things), reserve the upper, inaccessible bits, and things Should Work?
> Unless you're keeping some MMIO ranges up there, in which case, the
> solution is probably hard.

I agree that 5-level paging is only needed when very high MMIO is needed for
silicon init.

> 
> --
> Pedro
> 
> 
> 
>