From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vq6CV-0002LR-Tb for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 14:09:03 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq6CM-0002JI-MU for grub-devel@gnu.org; Mon, 09 Dec 2013 14:09:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq6CE-0006qN-8R for grub-devel@gnu.org; Mon, 09 Dec 2013 14:08:54 -0500 Received: from mail-ee0-x22c.google.com ([2a00:1450:4013:c00::22c]:49093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq6CE-0006qA-0n for grub-devel@gnu.org; Mon, 09 Dec 2013 14:08:46 -0500 Received: by mail-ee0-f44.google.com with SMTP id b57so1753798eek.31 for ; Mon, 09 Dec 2013 11:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=6tIpgGJVZp22Z1towXV/lENjdax/5euKsy76acm3Ue8=; b=UFiZyT7i2evt1PwRCiRE+za/2wSmhUP2atQJP/OyY3vXRGAaVfrzwNDtj9nfdPzdcT 65DUgfnk1ONsKn6onT3iZpEQCbR8UAlCI7Pqcy0y+gcfub4q8qitCK90Rygph+VV3/k9 bbF9mrxnK/8bYDPCJrDfue78HyjEFU5hJU6fZBIznoyImyMPhWF1bCpGzUeawHAK2iJB sRfgnOMCt6wcWCpfaFz9IFNGQunvMSyOCAQIKCqjdAHit3xXtB8bw9ThWAA6mAqtfTAS kd/p8fB4AEchHsYuW+pDTFhaxOR9uPXAwQRbVom7IB3H5YpBUA+GuMHi7qCV73hv0jUK qyug== X-Received: by 10.14.215.199 with SMTP id e47mr69814eep.107.1386616125173; Mon, 09 Dec 2013 11:08:45 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id n1sm32109965eep.20.2013.12.09.11.08.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 11:08:40 -0800 (PST) Message-ID: <52A61537.7030407@gmail.com> Date: Mon, 09 Dec 2013 20:08:39 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: kern/efi/mm.c - MAX_USABLE_ADDRESS References: <20131209173036.GK24997@rocoto.smurfnet.nu> In-Reply-To: <20131209173036.GK24997@rocoto.smurfnet.nu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lr7dWQwslgX2cSmKVCJKdI0NSGgPa7EtX" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22c X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lr7dWQwslgX2cSmKVCJKdI0NSGgPa7EtX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09.12.2013 18:30, Leif Lindholm wrote: > Hi, >=20 > The EFI memory management code contains a hard-wired limit restricting > physical (and virtual, all 1:1 mapped in UEFI) addresses to 32-bit. > While this may be the right thing to do on x86, and hasn't caused me > any issues on 32-bit ARM, I have received reports of at least two > upcoming 64-bit ARM platforms with no RAM in the lower 4GB of physical > address space. >=20 > A simple fix would be to just stack the ifdefs, but a better one might > be to move the define to one of (which is currently > a dummy for all platforms, simply including ) or types.h.= >=20 cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at least partially, EFI limitation (due to EFI bugs), not CPU. Real restrictions is a mix of unrelated restriction but it seem to align well with CPU. Increasing it beyond 0xffffffff will need chacking that efi/mm.c can handle it without overflow. The limits are: -0xffffffff on 32-bit platforms due to address space size (i386, arm) -0x7fffffff when x86_64 compiled without -mcmodel=3Dlarge due to compiler= assumptions -0xffffffff on x86_64 because some EFI implementations don't map memory above 4G contrary to spec. - On ia64 it's probably unlimited but I didn't test and there is always a danger of EFI bugs similar to x86_64 one, so better to be conservative about it - arm64. You're the expert. > --- a/include/grub/i386/types.h > +++ b/include/grub/i386/types.h > @@ -25,6 +25,12 @@ > /* The size of long. */ > #define GRUB_TARGET_SIZEOF_LONG 4 > =20 > +#if defined (__code_model_large__) > +#define MAX_USABLE_ADDRESS 0xffffffff > +#else > +#define MAX_USABLE_ADDRESS 0x7fffffff > +#endif > + Should be MAX_USABLE_ADDRESS 0xffffffff --lr7dWQwslgX2cSmKVCJKdI0NSGgPa7EtX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlKmFTcACgkQmBXlbbo5nOswrAD/fUXPzJmKs7J2zj7ydGPv8UBZ QEPNR5kvD67sQYV4JS4A/RYjNwnoQDrlkZExGHdBMIfv45me+XnkAHmGD2j4FQ77 =xJen -----END PGP SIGNATURE----- --lr7dWQwslgX2cSmKVCJKdI0NSGgPa7EtX--