Re: kern/efi/mm.c - MAX_USABLE_ADDRESS

[Leif Lindholm]

On Mon, Dec 09, 2013 at 08:08:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> > 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.

Ah, ok - that makes sense then.

> 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.

Thank you - that makes it very clear.

/
    Leif