[RFC] arm64: defconfig: enable 48-bit VA by default
Catalin Marinas
catalin.marinas at arm.com
Fri Aug 14 08:37:22 PDT 2015
On Fri, Aug 14, 2015 at 03:55:19PM +0200, Ard Biesheuvel wrote:
> On 14 August 2015 at 15:24, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Aug 14, 2015 at 02:15:23PM +0200, Ard Biesheuvel wrote:
> >> >> 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.
> > [...]
> >> So we still need to decide how to fix the case where the linear region
> >> is not of sufficient size to cover all of memory, considering that is
> >> what got this discussion started in the first place.
> >
> > We already have a solution, just enable 4-levels of page tables (only
> > that I don't think we should change defconfig as well).
> >
> > If we want to do any tricks like compacting the memory range, it needs
> > to be backed by benchmarks to prove that it's worth compared to a full
> > 48-bit VA.
>
> If you run a 39-bit VA kernel on a system whose DRAM configuration
> covers a larger area than what the linear mapping can support, you
> currently get a panic since phys_to_virt() overflows into the user
> range. So at the very least, we need to clip the range to a size the
> kernel can manage.
Yes, this needs fixing (clipping looks like the best option).
--
Catalin
More information about the linux-arm-kernel
mailing list