[RFC PATCH v1 0/3] Update tlb invalidation routines for FEAT_LPA2

[Ard Biesheuvel]

On Mon, 13 Nov 2023 at 22:20, Marc Zyngier <maz at kernel.org> wrote:
>
> On Mon, 13 Nov 2023 11:55:01 +0000,
> Ryan Roberts <ryan.roberts at arm.com> wrote:
> >
> > On 27/10/2023 12:56, Ryan Roberts wrote:
> > > Hi All,
> > >
> > > As raised yesterday against Ard's LPA2 series [1], we need to address the TLBI
> > > changes to properly support LPA2 before Ard's changes get merged. So far those
> > > changes have been part of my KVM LPA2 series [2]. So this is an attempt to split
> > > the TLBI changes to make them independent. The idea is that this series would go
> > > in first, then Ard's and the rest of my series can race eachother and it doesn't
> > > really matter who wins.
> > >
> > > I've attempted to address all of Marc's feedback against the versions of these
> > > patches posted at [2], including adding benchmark data (see patch 1). Although
> > > if people are still nervous that this could regress non-lpa2 performance in some
> > > cases, I could rework so that there are lpa2 and non-lpa2 variants of
> > > __flush_tlb_range_op(), and the correct version is chosen at the higher level
> > > (based on lpa2_is_enabled() / kvm_lpa2_is_enabled()).
> > >
> > > It turns out that we won't be able to key LPA2 usage off the same static key for
> > > both the kernel and kvm usage because the kernel usage additionally depends on
> > > CONFIG_ARM64_LPA2 being enabled. So I've introduced 2 stub functions
> > > (lpa2_is_enabled() and kvm_lpa2_is_enabled()) to advertise it. Ard already
> > > defines and implements lpa2_is_enabled() in his series, so there will be a minor
> > > conflict to resolve there. I plan to define kvm_lpa2_is_enabled() to be the
> > > static key for kvm in my series. Marc, would you be happy with this approach?
> > >
> > > Anyway, I wanted to put this out there as an RFC. If we are happy with it, then
> > > I'll re-post on 6.7-rc1.
> >
> > Marc, All,
> >
> > I polite bump; I never heard back on this. I'm planning to post my LPA2/KVM
> > series on top of v6.7-rc1 in the next day or 2. By default, these 3 patches will
> > be the first 3 of the series. But if you have an issue with the approach it
> > would be good to work out an alternative plan to avoid wasting effort preparing
> > the series.
>
> No specific concern on the approach. Having a static-key for the KVM
> side is good, and the uplift on the range stuff seems compelling.
>

OK, I'll put these at the start of my ++v as well.

Thanks,