[RFC PATCH] arm64: mm: increase VA range of identity map

[Ard Biesheuvel]

On 24 February 2015 at 14:43, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Tue, Feb 24, 2015 at 12:18:26PM +0000, Ard Biesheuvel wrote:
>> On 24 February 2015 at 12:03, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Tue, Feb 24, 2015 at 10:55:42AM +0000, Ard Biesheuvel wrote:
>> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> >> index f800d45ea226..19f6297a472b 100644
>> >> --- a/arch/arm64/include/asm/memory.h
>> >> +++ b/arch/arm64/include/asm/memory.h
>> >> @@ -42,12 +42,14 @@
>> >>   * PAGE_OFFSET - the virtual address of the start of the kernel image (top
>> >>   *            (VA_BITS - 1))
>> >>   * VA_BITS - the maximum number of bits for virtual addresses.
>> >> + * MAX_VA_BITS - architectural max value for VA_BITS
>> >>   * TASK_SIZE - the maximum size of a user space task.
>> >>   * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
>> >>   * The module space lives between the addresses given by TASK_SIZE
>> >>   * and PAGE_OFFSET - it must be within 128MB of the kernel text.
>> >>   */
>> >>  #define VA_BITS                      (CONFIG_ARM64_VA_BITS)
>> >> +#define MAX_VA_BITS          48
>> >
>> > Can we determine this dynamically based on the phys address? So on
>> > hardware that doesn't need such large idmap, it would stick to the host
>> > configured levels.
>>
>> I guess we could. Is there a benefit to keeping TCR.T0SZ as high as
>> possible if you are adding the additional level anyway?
>> It only costs us one page regardless, and only if the runtime check
>> shows that system RAM exceeds VA_BITS
>
> It's not the page that we may waste in the idmap table but higher T0SZ
> implies deeper translation tables, so an additional page table walk
> during power up/down sequences.
>

OK, but the patch only modifies T0SZ from the default if the system
RAM is observed to be out of reach at runtime, and so MAX_VA_BITS is
only used in that case. For both 4k and 64k pages, this will configure
one additional level of translation. Does it still matter then which
exact T0SZ value is used between the possible values that all
correspond with 4 levels, for instance?

I think it is cleaner to use the PA of KERNEL_END, as you suggest, so
I am removing MAX_VA_BITS anyway, but I am just curious.

> We could populate the idmap table as maximum number of levels
> permanently (based on MAX_VA_BITS) but set T0SZ according to the SoC
> needs and TTBR0_EL1 may need to skip the first page of the original
> idmap (we do something similar in arch/arm/mm/proc-v7-3level.S with
> TTBR1_OFFSET since for 1GB of kernel linear mapping we only need 2
> levels but swapper_pg_dir is always 3).
>