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

[Jonathan Cameron]

On Wed, 23 Sep 2026 00:21:58 +0100
Suzuki K Poulose <suzuki.poulose at 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 at 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 at 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 at 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?

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