Re: [PATCH v2 25/28] KVM: x86/mmu: Allow zapping collapsible SPTEs to use MMU read lock
From: Ben Gardon
Date: Wed Feb 03 2021 - 13:54:05 EST
On Wed, Feb 3, 2021 at 3:34 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On 02/02/21 19:57, Ben Gardon wrote:
> > @@ -1485,7 +1489,9 @@ void kvm_tdp_mmu_zap_collapsible_sptes(struct kvm *kvm,
> > struct kvm_mmu_page *root;
> > int root_as_id;
> >
> > - for_each_tdp_mmu_root_yield_safe(kvm, root, false) {
> > + read_lock(&kvm->mmu_lock);
> > +
> > + for_each_tdp_mmu_root_yield_safe(kvm, root, true) {
> > root_as_id = kvm_mmu_page_as_id(root);
> > if (root_as_id != slot->as_id)
> > continue;
> > @@ -1493,6 +1499,8 @@ void kvm_tdp_mmu_zap_collapsible_sptes(struct kvm *kvm,
> > zap_collapsible_spte_range(kvm, root, slot->base_gfn,
> > slot->base_gfn + slot->npages);
> > }
> > +
> > + read_unlock(&kvm->mmu_lock);
> > }
>
>
> I'd prefer the functions to be consistent about who takes the lock,
> either mmu.c or tdp_mmu.c. Since everywhere else you're doing it in
> mmu.c, that would be:
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 0554d9c5c5d4..386ee4b703d9 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -5567,10 +5567,13 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
> write_lock(&kvm->mmu_lock);
> slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
> kvm_mmu_zap_collapsible_spte, true);
> + write_unlock(&kvm->mmu_lock);
>
> - if (kvm->arch.tdp_mmu_enabled)
> + if (kvm->arch.tdp_mmu_enabled) {
> + read_lock(&kvm->mmu_lock);
> kvm_tdp_mmu_zap_collapsible_sptes(kvm, memslot);
> - write_unlock(&kvm->mmu_lock);
> + read_unlock(&kvm->mmu_lock);
> + }
> }
>
> void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm,
>
> and just lockdep_assert_held_read here.
That makes sense to me, I agree keeping it consistent is probably a good idea.
>
> > - tdp_mmu_set_spte(kvm, &iter, 0);
> > -
> > - spte_set = true;
>
> Is it correct to remove this assignment?
No, it was not correct to remove it. Thank you for catching that.
>
> Paolo
>