On 11/29/18 15:59, Gao, Liming wrote: > Laszlo: > I add my comments. > > Thanks > Liming >> -----Original Message----- >> From: Laszlo Ersek [mailto:[email protected]] >> Sent: Tuesday, November 27, 2018 10:52 PM >> To: Ard Biesheuvel <[email protected]>; [email protected] >> Cc: Gao, Liming <[email protected]>; Kinney, Michael D >> <[email protected]>; [email protected]; >> [email protected] >> Subject: Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 >> bits >> >> On 11/27/18 13:27, Ard Biesheuvel wrote: >>> AArch64 support the use of more than 48 bits for physical and/or >>> virtual addressing, but only if the page size is set to 64 KB, >>> which is not supported by UEFI/EDK2. So redefine MAX_ADDRESS to >>> cover only 48 address bits. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ard Biesheuvel <[email protected]> >>> --- >>> MdePkg/Include/AArch64/ProcessorBind.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/MdePkg/Include/AArch64/ProcessorBind.h >>> b/MdePkg/Include/AArch64/ProcessorBind.h >>> index 968c18f915ae..dad75df1c579 100644 >>> --- a/MdePkg/Include/AArch64/ProcessorBind.h >>> +++ b/MdePkg/Include/AArch64/ProcessorBind.h >>> @@ -138,9 +138,9 @@ typedef INT64 INTN; >>> #define MAX_2_BITS 0xC000000000000000ULL >>> >>> /// >>> -/// Maximum legal AARCH64 address >>> +/// Maximum legal AARCH64 address (48 bits for 4 KB page size) >>> /// >>> -#define MAX_ADDRESS 0xFFFFFFFFFFFFFFFFULL >>> +#define MAX_ADDRESS 0xFFFFFFFFFFFFULL >>> >>> /// >>> /// Maximum legal AArch64 INTN and UINTN values. >>> >> >> Hmmmm. I'm worried about this change. I think it could open a can of >> worms. I have no clue what *all* the things are that we use MAX_ADDRESS >> for. Does it give the maximum value of the canonical address *format*? >> Or is it the maximum address that the processor could ever access? >> >> Let's look at the X64 situation... For X64, MAX_ADDRESS is >> 0xFFFF_FFFF_FFFF_FFFF_ULL (MdePkg/Include/X64/ProcessorBind.h). However, >> on X64, even considering the recently introduced 5-level paging >> <https://en.wikipedia.org/wiki/Intel_5-level_paging>, the "useful" >> number of address bits is up to just 57 -- it used to be 48, with >> 4-level paging. That is: not 64. Yet we have MAX_UINT64 for MAX_ADDRESS! >> >> Which in turn means that, with X64 5-level paging in mind, the issue >> affects X64 as well -- there could be RAM in the system that the 64-bit >> DXE phase couldn't access (because edk2 doesn't support 5-level paging, >> AIUI), but the OS could. >> >> That officially turns the question into a multi-architectural one: how >> should the UEFI memmap describe the highest RAM range, such that it be >> exposed to the OS, but not exposed to the firmware itself? (Because, the >> firmware doesn't support the necessary paging mode, or processor mode.) >> >> Liming, can you share what Intel plans, in edk2, for supporting 5-level >> paging? > So far, I have no more to be shared. I don't know whether it is necessary to > support 5-level paging with the max memory. > The firmware can report [2^48 .. 2^57) RAM with the allocated status. So, > those region memory can't be allocated in firmware. > They will be visible to OS. If OS enables 5-level paging, it can access them.
Great, thank you! Laszlo >> >> And, on such physical X64 systems today that support 57-bit paging, how >> does the UEFI memmap describe the [2^48 .. 2^57) RAM? >> >> And how does the firmware allocate and use memory from that area? >> >> Thanks, >> Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
