* [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits @ 2018-11-27 12:27 Ard Biesheuvel 2018-11-27 13:38 ` Leif Lindholm 2018-11-27 14:51 ` Laszlo Ersek 0 siblings, 2 replies; 5+ messages in thread From: Ard Biesheuvel @ 2018-11-27 12:27 UTC (permalink / raw) To: edk2-devel Cc: liming.gao, michael.d.kinney, leif.lindholm, lersek, philmd, Ard Biesheuvel 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 <ard.biesheuvel@linaro.org> --- 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. -- 2.19.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits 2018-11-27 12:27 [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits Ard Biesheuvel @ 2018-11-27 13:38 ` Leif Lindholm 2018-11-27 14:51 ` Laszlo Ersek 1 sibling, 0 replies; 5+ messages in thread From: Leif Lindholm @ 2018-11-27 13:38 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: edk2-devel, liming.gao, michael.d.kinney, lersek, philmd On Tue, Nov 27, 2018 at 01:27:48PM +0100, Ard Biesheuvel wrote: > AArch64 support the use of more than 48 bits for physical and/or supports > 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 s/EDK2// With those tweaks: Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> > cover only 48 address bits. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > 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. > -- > 2.19.1 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits 2018-11-27 12:27 [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits Ard Biesheuvel 2018-11-27 13:38 ` Leif Lindholm @ 2018-11-27 14:51 ` Laszlo Ersek 2018-11-29 14:59 ` Gao, Liming 1 sibling, 1 reply; 5+ messages in thread From: Laszlo Ersek @ 2018-11-27 14:51 UTC (permalink / raw) To: Ard Biesheuvel, edk2-devel Cc: liming.gao, michael.d.kinney, leif.lindholm, philmd 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 <ard.biesheuvel@linaro.org> > --- > 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? 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits 2018-11-27 14:51 ` Laszlo Ersek @ 2018-11-29 14:59 ` Gao, Liming 2018-11-29 18:02 ` Laszlo Ersek 0 siblings, 1 reply; 5+ messages in thread From: Gao, Liming @ 2018-11-29 14:59 UTC (permalink / raw) To: Laszlo Ersek, Ard Biesheuvel, edk2-devel@lists.01.org Cc: Kinney, Michael D, leif.lindholm@linaro.org, philmd@redhat.com Laszlo: I add my comments. Thanks Liming > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Tuesday, November 27, 2018 10:52 PM > To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel@lists.01.org > Cc: Gao, Liming <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; leif.lindholm@linaro.org; > philmd@redhat.com > 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 <ard.biesheuvel@linaro.org> > > --- > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits 2018-11-29 14:59 ` Gao, Liming @ 2018-11-29 18:02 ` Laszlo Ersek 0 siblings, 0 replies; 5+ messages in thread From: Laszlo Ersek @ 2018-11-29 18:02 UTC (permalink / raw) To: Gao, Liming, Ard Biesheuvel, edk2-devel@lists.01.org Cc: Kinney, Michael D, leif.lindholm@linaro.org, philmd@redhat.com On 11/29/18 15:59, Gao, Liming wrote: > Laszlo: > I add my comments. > > Thanks > Liming >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Tuesday, November 27, 2018 10:52 PM >> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel@lists.01.org >> Cc: Gao, Liming <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; leif.lindholm@linaro.org; >> philmd@redhat.com >> 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 <ard.biesheuvel@linaro.org> >>> --- >>> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-11-29 18:02 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-11-27 12:27 [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits Ard Biesheuvel 2018-11-27 13:38 ` Leif Lindholm 2018-11-27 14:51 ` Laszlo Ersek 2018-11-29 14:59 ` Gao, Liming 2018-11-29 18:02 ` Laszlo Ersek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox