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

[Catalin Marinas]

On Thu, Jul 30, 2015 at 09:27:03PM +0200, Ard Biesheuvel wrote:
> On 30 July 2015 at 12:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Wed, Jul 29, 2015 at 08:49:57PM +0000, Stuart Yoder wrote:
> >> > From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> [...]
> >> > To be honest, I think this is poorly designed, and I am not sure we
> >> > should cater for such configurations in the defconfig.
> >>
> >> Agree, if this is a one-off weird platform then we shouldn't.
> >>
> >> But, the 'Principles of ARM Memory Maps' doc proposes this:
> >> 2 GB at 0x8000_0000
> >> 30 GB at 0x8_8000_0000
> >> 480 GB at 0x88_0000_0000
> >
> > I'm not particularly recommending this layout, at least not without some
> > clarifications on DRAM aliases (I'll ping people internally about it
> > again). The original layout pre-dates ARMv8, it was meant for ARMv7/LPAE
> > and all the memory beyond 32-bit was highmem anyway. It was later
> > updated for AArch64 but only to allow 44/48-bit PA (a few sections
> > added).
> 
> As an aside, is there any reason why the direct mapping *must* be a
> linear mapping?
> Other than the performance concerns regarding
> phys_to_virt/virt_to_phys, I mean?

Mostly performance concerns. You could compact the physical range into a
smaller virtual one but the conversion will be costly, especially if you
want to make it multi-platform (having to look-up memory ranges,
memblock offsets). This would affect page table entry setup, code that
requires a page structure (like virt_to_page) and anything else doing
the virt/phys conversion.

I tried something like that for RealView PBX in the past but it was
hard-coded (no multi-platform at the time). See
arch/arm/mach-realview/include/mach/memory.h.

As for the mem_map array, on arm64 we have enough VA space available
(with vmemmap it takes a few GB to cover a 512GB RAM space).

-- 
Catalin