On 25/02/2016 10:10, Xiao Guangrong wrote: > > > On 02/25/2016 04:49 PM, Paolo Bonzini wrote: >> >> >> On 25/02/2016 08:35, Xiao Guangrong wrote: >>>> This may release the mmu_lock before committing the zapping. >>>> Is it safe? If so, we may want to see the reason in the changelog. >>> >>> It is unsafe indeed, please do not do it. >> >> Can you explain why? kvm_zap_obsolete_pages does the same. > > It's not the same, please see the comment in > kvm_mmu_invalidate_zap_all_pages: > /* > * Notify all vcpus to reload its shadow page table > * and flush TLB. Then all vcpus will switch to new > * shadow page table with the new mmu_valid_gen. > * > * Note: we should do this under the protection of > * mmu-lock, otherwise, vcpu would purge shadow page > * but miss tlb flush. > */ > kvm_reload_remote_mmus(kvm); > > That means the tlb is flushed before releasing mmu-lock. > > A example is in rmap_write_protect(), when KVM creates a shadow page > table for > the the guest, it detects no spte pointing to the gfn, so tlb is not > flushed so > that guest can freely updates its pte. Then I'll do a different patch that checks need_resched||spin_needbreak, and if so does commit+cond_resched_lock. I've removed 9/12 from kvm/queue. Again, sorry for giving the impression that these patches were already final. Paolo -- 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
