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

[Ard Biesheuvel]

On 31 July 2015 at 14:53, Catalin Marinas <catalin.marinas at 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 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.
>

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 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.



> 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