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 C351B21195BD1 for ; Tue, 27 Nov 2018 06:52:21 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3845B308FB92; Tue, 27 Nov 2018 14:52:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-96.rdu2.redhat.com [10.10.120.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id A4AB950C13; Tue, 27 Nov 2018 14:51:51 +0000 (UTC) To: Ard Biesheuvel , edk2-devel@lists.01.org Cc: liming.gao@intel.com, michael.d.kinney@intel.com, leif.lindholm@linaro.org, philmd@redhat.com References: <20181127122748.24527-1-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <6f1209fb-bb89-a70f-ba0e-3ebf2e12e459@redhat.com> Date: Tue, 27 Nov 2018 15:51:50 +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: <20181127122748.24527-1-ard.biesheuvel@linaro.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Tue, 27 Nov 2018 14:52:21 +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: Tue, 27 Nov 2018 14:52:21 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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? 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