From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1E6C8211963E0 for ; Thu, 29 Nov 2018 02:41:01 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id m8so7086725itk.0 for ; Thu, 29 Nov 2018 02:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XA6uxB+PkXm3GrjMroUgiTZ4MGjQLwJ6q37cEbVj6us=; b=Wk+ZiZQgQ6PKn8HEVRRWox6aP+0RCKOwhb0ViY6a1ugMZJInRIDVLqO9sZYX7S21rC IEwZOblir3qSwgL5Uw+sftqpQUomKplPtimoo6Aq9ra5anR6pHjq8dQoZSlc+C9DHuXl XORymcldplRWnqZOe+zFm32vGblsAVDp9YvPQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XA6uxB+PkXm3GrjMroUgiTZ4MGjQLwJ6q37cEbVj6us=; b=bW9NM0NQYLvavH0jpd5ZwxZzGiOlw3Bujppxrm5Ih0mhBL6e3aN8vYsPrgPKq5zN4h BTVoE3rg9wxPR6t99yPaSZ+LHaWTWSzTEnkskKN1CWflHdODYd0lUzWl2I78mGYxhhF3 LipOEQtw3DPiZ1g+zUedeDpmoKSjCRR0shwLBURQQwU70b4wCRgZgWIMJ2ueoS5J11+S 4/u4kRichAevvz+/glDkZrbqjii36GI9jk1wpeVdC3Rl37gq5+uZ/KNmLIdBy2XLAsV7 vG67MtVI4DEijFmTTqT5vCXLPwXXa2iJnBXQSoMnISZPWjZ0svixcEXR/Gu1+/hOnvlX gyvw== X-Gm-Message-State: AA+aEWZLibtDS+1pAOsjWtv0I2P9Bo7zgafzX014OcPssJobUVkZALXU kWXC8jAVrunzCWcrO/HRcSJA3YuYLDNfghNJxAjzQA== X-Google-Smtp-Source: AFSGD/XLp3slY8MStq7kxxHHOcd8IhE0piNY/Yq2IfXYyRKhoj4cP1ipdmZ6LWXmwqxLvfIbomAyQSeDpqXRwh6vMeY= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr1021887itk.71.1543488060474; Thu, 29 Nov 2018 02:41:00 -0800 (PST) MIME-Version: 1.0 References: <20181128143357.991-1-ard.biesheuvel@linaro.org> <20181128143357.991-6-ard.biesheuvel@linaro.org> <8ad971d4-c8d8-2f6e-0d60-c61e4ed362d7@redhat.com> In-Reply-To: <8ad971d4-c8d8-2f6e-0d60-c61e4ed362d7@redhat.com> From: Ard Biesheuvel Date: Thu, 29 Nov 2018 11:40:49 +0100 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Auger Eric , Andrew Jones , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Julien Grall 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 10:41:02 -0000 Content-Type: text/plain; charset="UTF-8" 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? > We're not much past the last stable tag (edk2-stable201811), so let's > hope there's going to be enough time to catch any regressions. > > With (a) and (b) investigated / fixed up, I'd be willing to A-b this. > Cautiously :) > Thanks > Anyway, this is for MdePkg, so my review is not required. (I certainly > do not intend to *oppose* this patch.) > > Thanks > Laszlo