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

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

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.

Cheers
Suzuki


> 
>> +}
> 
>