Re: [PATCH v19 09/20] KVM: arm64: Add VM specific callback for S2 MMU operations

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 23/09/2026 17:54, Jonathan Cameron wrote:
> On Wed, 23 Sep 2026 00:21:58 +0100
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> 
>> On 22/09/2026 23:29, Jonathan Cameron wrote:
>>> On Sun, 20 Sep 2026 22:28:34 +0100
>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>    
>>>> Add VM type specific S2 MMU operation backends which can be initialized per
>>>> VM flavor, to keep the handling cleaner.
>>>>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>
>>> A small suggestion inline that makes it explicit when there isn't
>>> range operation and a full flush of tlb is needed.
>>>
>>> I don't mind either way, but thought I'd mention it anyway in case
>>> you hadn't already dismissed it.
>>>
>>> Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
>>>
>>>    
>>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>>> index 03f2017a7404a..d97a4a1bca23f 100644
>>>> --- a/arch/arm64/kvm/mmu.c
>>>> +++ b/arch/arm64/kvm/mmu.c
>>>> @@ -37,6 +37,8 @@ static unsigned long __ro_after_init io_map_base;
>>>>    
>>>>    #define KVM_PGT_FN(fn)		(!is_protected_kvm_enabled() ? fn : p ## fn)
>>>>      
>>>    
>>>>    /**
>>>>     * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8
>>>>     * @kvm:	pointer to kvm structure.
>>>> @@ -174,26 +188,36 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot)
>>>>     */
>>>>    int kvm_arch_flush_remote_tlbs(struct kvm *kvm)
>>>>    {
>>>> -	if (is_protected_kvm_enabled())
>>>> -		kvm_call_hyp_nvhe(__pkvm_tlb_flush_vmid, kvm->arch.pkvm.handle);
>>>> -	else
>>>> -		kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu);
>>>> -	return 0;
>>>> +	if (!kvm->arch.vm_s2_ops->vm_flush_remote_tlbs)
>>>> +		return 1;
>>>
>>> For consistency with other cases and because it looks nicer
>>> blank line here.
>>
>> Ack
>>
>>>    
>>>> +	return kvm->arch.vm_s2_ops->vm_flush_remote_tlbs(kvm);
>>>>    }
>>>>    
>>>> -int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm,
>>>> -				      gfn_t gfn, u64 nr_pages)
>>>> +static int pkvm_flush_remote_tlbs_range(struct kvm *kvm,
>>>> +					gfn_t gfn, u64 nr_pages)
>>>> +{
>>>> +	return pkvm_flush_remote_tlbs(kvm);
>>>
>>> For the cases where there isn't a range call, perhaps you should just
>>> not provide the op and have the wrapper fall back to
>>> calling the 'flush all' variant if there is no range one available?
>>
>> The core KVM falls back to flushing all TLBs if the range one
>> returns true anyways. So, I would leave it as it is.
> 
> That sounds like a reason to stub them to return true always rather
> than call the flush all so we don't have fallbacks added at two
> layers of the stack?

But that doesn't help, as the only one that matters is pKVM, which
handles this anyway. If tlbs_range is not available, then the
all tlbs call back also return the same value. So, the core is
anyway going to call the full version anyways.

So I have left it as it is. A sensible backend could do
something like the pKVM does.

Cheers
Suzuki



> 
>>
>> Cheers
>> Suzuki
>>
>>
>>>    
>>>> +}
>>>
>>>    
>>
> 
>