[PATCH 2/3] arm64: mm: Handle LVA support as a CPU feature

[Catalin Marinas]

On Wed, Nov 30, 2022 at 03:56:26PM +0100, Ard Biesheuvel wrote:
> On Wed, 30 Nov 2022 at 15:50, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Nov 15, 2022 at 03:38:23PM +0100, Ard Biesheuvel wrote:
> > > Currently, we detect CPU support for 52-bit virtual addressing (LVA)
> > > extremely early, before creating the kernel page tables or enabling the
> > > MMU. We cannot override the feature this early, and so large virtual
> > > addressing is always enabled on CPUs that implement support for it if
> > > the software support for it was enabled at build time. It also means we
> > > rely on non-trivial code in asm to deal with this feature.
> > >
> > > Given that both the ID map and the TTBR1 mapping of the kernel image are
> > > guaranteed to be 48-bit addressable, it is not actually necessary to
> > > enable support this early, and instead, we can model it as a CPU
> > > feature. That way, we can rely on code patching to get the correct
> > > TCR.T1SZ values programmed on secondary boot and suspend from resume.
> > >
> > > On the primary boot path, we simply enable the MMU with 48-bit virtual
> > > addressing initially, and update TCR.T1SZ from C code if LVA is
> > > supported, right before creating the kernel mapping. Given that TTBR1
> > > still points to reserved_pg_dir at this point, updating TCR.T1SZ should
> > > be safe without the need for explicit TLB maintenance.
> >
> > I'm not sure we can skip the TLBI here. There's some weird rule in the
> > ARM ARM that if you change any of fields that may be cached in the TLB,
> > maintenance is needed even if the MMU is off. From the latest version
> > (I.a, I didn't dig into H.a),
> >
> > R_VNRFW:
> >   When a System register field is modified and that field is permitted
> >   to be cached in a TLB, software is required to invalidate all TLB
> >   entries that might be affected by the field, at any address
> >   translation stage in the translation regime even if the translation
> >   stage is disabled, using the appropriate VMID and ASID, after any
> >   required System register synchronization.
> 
> Don't we already rely on this in cpu_set_default_tcr_t0sz() /
> cpu_set_idmap_tcr_t0sz() ?

Yeah, we do this and depending on how you read the above rule, we may
need to move the local_flush_tlb_all() line after T0SZ setting.

-- 
Catalin