On Fri, Feb 10, 2012 at 03:52:49PM +0800, Xiao Guangrong wrote: > On 02/10/2012 02:28 PM, Takuya Yoshikawa wrote: > > > Other threads may process the same page in that small window and skip > > TLB flush and then return before these functions do flush. > > > > > It is possible that flush tlb in mmu lock only when writeable > spte is invalided? Sometimes, kvm_flush_remote_tlbs need > long time to wait.
readonly isn't enough to defer the flush after mmu_lock is released... if you do it only for writable spte, then what can happen is the guest may read random data and would crash. However for this case, the mmu_notifier methods (and only them) are perfectly safe to flush the shadow MMU TLB after the mmu_lock is released because the page reference is guaranteed hold by the caller (not the case for any other place where a spte gets dropped in KVM, all other places dropping sptes, can only on the mmu notifier to block on the mmu_lock in order to have a guarantee of the page not being freed under them, so in every other place the shadow MMU TLB flush must happen before releasing the mmu_lock so the mmu_notifier will wait and prevent the page to be freed until all other CPUs running in guest mode stopped accessing it). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
