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 6193821962301 for ; Fri, 7 Dec 2018 04:54:11 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D38773005163; Fri, 7 Dec 2018 12:54:10 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-214.rdu2.redhat.com [10.10.120.214]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5FCF828D22; Fri, 7 Dec 2018 12:54:00 +0000 (UTC) To: Ard Biesheuvel , edk2-devel@lists.01.org Cc: Michael D Kinney , Liming Gao , Jian J Wang , Hao Wu , Leif Lindholm , Eric Auger , Andrew Jones , Philippe Mathieu-Daude References: <20181207112304.19765-1-ard.biesheuvel@linaro.org> <20181207112304.19765-2-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <191094c5-2ccf-a298-b67f-df366775efee@redhat.com> Date: Fri, 7 Dec 2018 13:53:54 +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: <20181207112304.19765-2-ard.biesheuvel@linaro.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Fri, 07 Dec 2018 12:54:11 +0000 (UTC) Subject: Re: [RFC PATCH 1/7] MdePkg/Base: introduce MAX_ALLOC_ADDRESS 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: Fri, 07 Dec 2018 12:54:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 12/07/18 12:22, Ard Biesheuvel wrote: > On some architectures, the maximum representable address deviates from > the virtual address range that is accessible by the firmware at boot > time. For instance, on AArch64, UEFI mandates a 4 KB page size, which > limits the address space to 48 bits, while more than that may be > populated on a particular platform, for use by the OS. > > So introduce a new macro MAX_ALLOC_ADDRESS, which represent the maximum > address the firmware should take into account when allocating memory > ranges that need to be accessible by the CPU at boot time. Initially, > it just defaults to MAX_ADDRESS, but later on, architectures may elect > to override it to a smaller number. > > This means that all replacements of MAX_ADDRESS with MAX_ALLOC_ADDRESS > are functional no-ops unless an architecture sets a value for the latter. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > MdePkg/Include/Base.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h > index bc877d8125a5..618f8ea85ce7 100644 > --- a/MdePkg/Include/Base.h > +++ b/MdePkg/Include/Base.h > @@ -404,6 +404,10 @@ struct _LIST_ENTRY { > #define MIN_INT32 (((INT32) -2147483647) - 1) > #define MIN_INT64 (((INT64) -9223372036854775807LL) - 1) > > +#ifndef MAX_ALLOC_ADDRESS > +#define MAX_ALLOC_ADDRESS MAX_ADDRESS > +#endif > + > #define BIT0 0x00000001 > #define BIT1 0x00000002 > #define BIT2 0x00000004 > Given that the page size is dictated by the spec, I think adding MAX_ALLOC_ADDRESS as a macro, and doing it here, is appropriate. Reviewed-by: Laszlo Ersek