On Wed, Mar 02, 2022, Mingwei Zhang wrote: > On Sat, Feb 26, 2022, Sean Christopherson wrote: > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c > > index 12866113fb4f..e35bd88d92fd 100644 > > --- a/arch/x86/kvm/mmu/tdp_mmu.c > > +++ b/arch/x86/kvm/mmu/tdp_mmu.c > > @@ -93,7 +93,15 @@ void kvm_tdp_mmu_put_root(struct kvm *kvm, struct kvm_mmu_page *root, > > list_del_rcu(&root->link); > > spin_unlock(&kvm->arch.tdp_mmu_pages_lock); > > > > - zap_gfn_range(kvm, root, 0, -1ull, false, false, shared); > > + /* > > + * A TLB flush is not necessary as KVM performs a local TLB flush when > > + * allocating a new root (see kvm_mmu_load()), and when migrating vCPU > > + * to a different pCPU. Note, the local TLB flush on reuse also > > + * invalidates any paging-structure-cache entries, i.e. TLB entries for > > + * intermediate paging structures, that may be zapped, as such entries > > + * are associated with the ASID on both VMX and SVM. > > + */ > > + (void)zap_gfn_range(kvm, root, 0, -1ull, false, false, shared); > > Understood that we could avoid the TLB flush here. Just curious why the > "(void)" is needed here? Is it for compile time reason? Nope, no functional purpose, though there might be some "advanced" warning or static checkers that care. The "(void)" is to communicate to human readers that the result is intentionally ignored, e.g. to reduce the probability of someone "fixing" the code by acting on the result of zap_gfn_range(). The comment should suffice, but it's nice to have the code be self-documenting as much as possible.