Re: [PATCH v3 15/15] KVM: MMU: replace kvm_zap_all withkvm_mmu_invalid_all_pages

[Marcelo Tosatti]

On Thu, Apr 18, 2013 at 12:03:45PM +0800, Xiao Guangrong wrote:
> On 04/18/2013 08:08 AM, Marcelo Tosatti wrote:
> > On Tue, Apr 16, 2013 at 02:32:53PM +0800, Xiao Guangrong wrote:
> >> Use kvm_mmu_invalid_all_pages in kvm_arch_flush_shadow_all and
> >> rename kvm_zap_all to kvm_free_all which is used to free all
> >> memmory used by kvm mmu when vm is being destroyed, at this time,
> >> no vcpu exists and mmu-notify has been unregistered, so we can
> >> free the shadow pages out of mmu-lock
> > 
> > Since there is no contention for mmu-lock its also not a problem to 
> > grab the lock right?
> 
> This still has contention. Other mmu-notify can happen when we handle
> ->release(). On the other handle, spin-lock is not preemptable.

Don't think so:

        kvm_coalesced_mmio_free(kvm);
#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
        mmu_notifier_unregister(&kvm->mmu_notifier, kvm->mm);
#else
        kvm_arch_flush_shadow_all(kvm);
#endif
        kvm_arch_destroy_vm(kvm);

> > Automated verification of locking/srcu might complain.
> 
> We hold slot-lock to free shadow page out of mmu-lock, it can avoid
> the complain. No?

Not if it realizes srcu is required to access the data structures.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/