From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 830532119621F for ; Thu, 29 Nov 2018 10:02:07 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D5E1F88E6D; Thu, 29 Nov 2018 18:02:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-125-13.rdu2.redhat.com [10.10.125.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 15F645B698; Thu, 29 Nov 2018 18:02:01 +0000 (UTC) To: "Gao, Liming" , Ard Biesheuvel , "edk2-devel@lists.01.org" Cc: "Kinney, Michael D" , "leif.lindholm@linaro.org" , "philmd@redhat.com" References: <20181127122748.24527-1-ard.biesheuvel@linaro.org> <6f1209fb-bb89-a70f-ba0e-3ebf2e12e459@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E380BE1@SHSMSX104.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <9bd35942-39f0-2219-fdbb-e4e958101c14@redhat.com> Date: Thu, 29 Nov 2018 19:02:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E380BE1@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 29 Nov 2018 18:02:07 +0000 (UTC) Subject: Re: [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 18:02:07 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 ; edk2-devel@lists.01.org >> Cc: Gao, Liming ; Kinney, Michael D ; 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 >>> --- >>> 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 >> , 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