Re: kern/efi/mm.c - MAX_USABLE_ADDRESS

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

signature.asc
Description: OpenPGP digital signature