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

[Ard Biesheuvel]

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() ?