Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits

[Laszlo Ersek <lersek@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