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. > > 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
