On Mon, Mar 16, 2009 at 06:01:52PM -0300, Marcelo Tosatti wrote: > On Mon, Mar 16, 2009 at 10:34:01PM +0200, Gleb Natapov wrote: > > > Doesnt the vm shutdown path rely on the while loop you removed to free > > > all shadow pages before freeing the mmu kmem caches, if mmu notifiers > > > is disabled? > > > > > Shouldn't mmu_free_roots() on all vcpus clear all mmu pages? > > No. It only zaps the present root on every vcpu, but not > the children. > > > > And how harmful is that loop? Zaps the entire cache on cpu hotunplug? > > > > > KVM doesn't support vcpu destruction, but destruction is called anyway > > on various error conditions. The one that easy to trigger is to create > > vcpu with the same id simultaneously from two threads. The result is > > OOPs in random places. > > mmu_lock should be held there, and apparently it is not. > Yeah, my first solution was to add mmu_lock, but why function that gets vcpu as an input should destroy data structure that is global for the VM. There is kvm_mmu_zap_all() that does same thing (well almost) and also does proper locking. Shouldn't it be called during VM destruction instead? -- Gleb. -- 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