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

[Ryan Roberts]

On 13/11/2023 12:29, Ard Biesheuvel wrote:
> 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.

Great - thanks both!

> 
> Thanks,
>