[RFC] arm64: defconfig: enable 48-bit VA by default

[Ard Biesheuvel]

On 7 aug. 2015, at 21:01, Stuart Yoder <stuart.yoder at freescale.com> wrote:

>> Whether defconfig supports your platform optimally has nothing to do
>> with that. Of course, we should deal with the unexpected memory layout
>> gracefully, which is why Mark Rutland and myself proposed patches to
>> fix the panic you reported. But in a development context, I think it
>> is perfectly acceptable to simply load the kernel at 0x80_8000_0000,
>> and be able to run defconfig fine while losing just 2 GB of your 16 GB
>> at the low end.
>
> I've done this experiment-- loading/running the kernel at 0x80_8000_0000
> and losing the lower 2GB of memory.  And in fact I can see the kernel
> ignoring the low memory:
>
>   [    0.000000] Ignoring memory block 0x80000000 - 0x100000000
>

Yes that looks correct

> However, this only works with 48-bit VA enabled.  With 39-bit VA
> enabled the kernel crashes before the early console is working
> and I see nothing.
>

That may well be a kernel bug: the changes to allow 39-bit VA kernels
to execute on systems whose memory is outside the 39-bit VA range was
developed and tested on AMD Seattle only, which has its RAM at
0x80_0000_0000. But it is hard to be sure, of course, with no output
at all ...

> Does the linear mapping we've been talking about just need to cover
> all of _RAM_, or does it need to cover all of I/O as well in
> the same mapping.
>
> In our case we have various SoC I/O devices, like the UART
> in the space below 4 GB... at 0x0100_0000.
>

The linear mapping only covers system RAM, so that should not matter at all.

> Before debugging further I want to check whether this should
> work in theory.  I had the impression that the issue was
> discontiguous RAM regions, and I/O was a separate issue.

Yes, it should work in theory. The linear region starts at the base of
the kernel Image, and extends all the way up to the end of DRAM (14 GB
in your case, IIRC)

-- 
Ard.