[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kern/efi/mm.c - MAX_USABLE_ADDRESS

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
Date: Mon, 09 Dec 2013 20:08:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

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
-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: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]