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

Catalin Marinas catalin.marinas at arm.com
Tue Feb 24 06:43:16 PST 2015


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.

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

-- 
Catalin



More information about the linux-arm-kernel mailing list