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

[catalin.marinas@arm.com (Catalin Marinas)]

On Fri, Jul 31, 2015 at 03:10:39PM +0200, Ard Biesheuvel wrote:
> On 31 July 2015 at 14:53, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Thu, Jul 30, 2015 at 09:27:03PM +0200, Ard Biesheuvel wrote:
> >> On 30 July 2015 at 12:13, Catalin Marinas <catalin.marinas@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.
> 
> Yes, that looks vaguely like what I had in mind.
> 
> IOW, we could partition the direct mapping just like the ARM
> recommendation, i.e.,
> 
> 0 - 2 GB
> 2 - 32 GB
> 32 - 512 GB
> 
> but default to 1:1 correspondence, so that
> 
> PHYS_OFFSET = PHYS_OFFSET0 = memstart_addr
> PHYS_OFFSET1 = memstart_addr + 2 GB
> PHYS_OFFSET2 = memstart_addr + 32 GB
> 
> and only if the ARM recommended physical memory map is detected (with
> memstart_addr @ 0x8000_0000), switch to
> 
> PHYS_OFFSET = PHYS_OFFSET0 = memstart_addr
> PHYS_OFFSET1 = memstart_addr + 30 GB
> PHYS_OFFSET2 = memstart_addr + 480 GB

I don't really like such complexity when all you need on arm64 is to
enable 48-bit VA (though it would be interesting to benchmark it).

> I guess such a special case would be out of the question for one-off
> crazy designs like Freescale, but since this is the layout recommended
> by ARM itself, I suppose we could try and support it a bit better.

I'm trying to get the layout fixed before it spreads any further ;).
Interestingly, SBSA doesn't mention this document at all.

-- 
Catalin