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 4136F21193078 for ; Thu, 29 Nov 2018 03:34:23 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 323F99FDC6; Thu, 29 Nov 2018 11:34:23 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-23.rdu2.redhat.com [10.10.121.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5CD7060F97; Thu, 29 Nov 2018 11:34:17 +0000 (UTC) To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Auger Eric , Andrew Jones , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Julien Grall References: <20181128143357.991-1-ard.biesheuvel@linaro.org> <20181128143357.991-6-ard.biesheuvel@linaro.org> <8ad971d4-c8d8-2f6e-0d60-c61e4ed362d7@redhat.com> From: Laszlo Ersek Message-ID: <4806d353-eeed-88a2-55ba-18cace17e281@redhat.com> Date: Thu, 29 Nov 2018 12:34:16 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 29 Nov 2018 11:34:23 +0000 (UTC) Subject: Re: [PATCH v3 05/16] 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 11:34:24 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/29/18 11:40, Ard Biesheuvel wrote: > On Wed, 28 Nov 2018 at 19:41, Laszlo Ersek wrote: >> >> On 11/28/18 15:33, Ard Biesheuvel wrote: >>> AArch64 supports 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. So redefine MAX_ADDRESS to cover >>> only 48 address bits. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ard Biesheuvel >>> Reviewed-by: Leif Lindholm >>> --- >>> 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. >>> >> >> Hmmm. >> >> I bit the bullet and grepped the tree for MAX_ADDRESS. >> >> The amount of hits is staggering. I can't audit all of them. >> >> Generally, MAX_ADDRESS seems to be used in checks that prevent address >> wrap-around. In that regard, this change looks valid. >> >> I can't guarantee this change won't regress anything though. In the >> previous posting of this patch, I asked Liming some questions (IIRC): >> >> http://mid.mail-archive.com/6f1209fb-bb89-a70f-ba0e-3ebf2e12e459@redhat.com >> >> It would be nice to see answers. :) >> > > Yep > >> In addition: >> >> (a) in "BaseTools/Source/C/Include/AArch64/ProcessorBind.h", we have >> another instance of the macro definition. I suspect it should be kept in >> sync. >> > > Indeed. > >> (b) in "BaseTools/Source/C/Common/CommonLib.h", we have: >> >> #define MAX_UINTN MAX_ADDRESS >> >> which I think relies on (a), and hence it will be amusingly wrong after >> we synchronize (a) with MdePkg. >> >> (BTW, (b) is exactly the kind of assumption that scares me about this >> patch.) >> > > That doesn't make any sense at all. What does 'native' mean in the > context of BaseTools anyway? I can't tell whether this MAX_UINTN definition is for BaseTools itself (i.e., "native") or for the build target arch. "CommonLib.c" has a number of instances of MAX_UINTN... Hm, they are in the following two functions: - StrDecimalToUintnS() -- wrapped by StrDecimalToUintn(), StrToIpv4Address(), and StrToIpv6Address()) - StrHexToUintnS() -- wrapped by StrHexToUintn(), and StrToIpv6Address(). I tried to look at where those are called from, and the picture remains muddled. For example, StrHexToUintn() is called from "BaseTools/Source/C/DevicePath/DevicePathFromText.c", functions EisaIdFromText() and DevPathFromTextNVMe(). These functions seem to compose binary devpath nodes from text *during the build*, likely for the firmware-under-build to consume as-is. Hence, this use of MAX_UINTN -- through StrHexToUintn() -- qualifies as *native* use. And for that, the MAX_UINTN definition in "CommonLib.h" looks wrong, independently of your patch series. Thanks Laszlo