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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
