[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
From: |
Leif Lindholm |
Subject: |
Re: kern/efi/mm.c - MAX_USABLE_ADDRESS |
Date: |
Mon, 9 Dec 2013 22:17:20 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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