All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
Date: Mon, 09 Dec 2013 20:08:39 +0100	[thread overview]
Message-ID: <52A61537.7030407@gmail.com> (raw)
In-Reply-To: <20131209173036.GK24997@rocoto.smurfnet.nu>

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

On 09.12.2013 18:30, Leif Lindholm wrote:
> Hi,
> 
> 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.
> 
> A simple fix would be to just stack the ifdefs, but a better one might
> be to move the define to one of <cpu/efi/memory.h> (which is currently
> a dummy for all platforms, simply including <efi/memory.h>) or types.h.
> 
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=large 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
>  
> +#if defined (__code_model_large__)
> +#define MAX_USABLE_ADDRESS             0xffffffff
> +#else
> +#define MAX_USABLE_ADDRESS             0x7fffffff
> +#endif
> +
Should be MAX_USABLE_ADDRESS             0xffffffff



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

  reply	other threads:[~2013-12-09 19:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-09 17:30 kern/efi/mm.c - MAX_USABLE_ADDRESS Leif Lindholm
2013-12-09 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-12-09 19:43   ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-09 21:26     ` Leif Lindholm
2013-12-09 21:17   ` Leif Lindholm
2013-12-10 14:59     ` Leif Lindholm
2013-12-10 16:00       ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-10 17:15         ` Leif Lindholm
2013-12-10 18:00           ` Vladimir 'φ-coder/phcoder' Serbinenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A61537.7030407@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.