From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: tlb flushing after spin_unlock of mmu lock Date: Thu, 16 Apr 2009 16:19:20 -0300 Message-ID: <20090416191920.GB15317@amt.cnet> References: <804dabb00904102145r446de3dfw6e2a287736fb170c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Peter Teoh Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59277 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757664AbZDPTUV (ORCPT ); Thu, 16 Apr 2009 15:20:21 -0400 Content-Disposition: inline In-Reply-To: <804dabb00904102145r446de3dfw6e2a287736fb170c@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: Peter, On Sat, Apr 11, 2009 at 12:45:21AM -0400, Peter Teoh wrote: > In this function, the TLB flushing comes before spin unlock, > > void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot) > { > struct kvm_mmu_page *sp; > > spin_lock(&kvm->mmu_lock); > > kvm_flush_remote_tlbs(kvm); > spin_unlock(&kvm->mmu_lock); > } kvm_vm_ioctl_get_dirty_log does: down_write(slots_lock) - collect data from dirty bitmap (kvm_get_dirty_log) if (something was dirty) - remove write access for all translations - flush remote tlb's - clear the dirty bitmap up_write(slots_lock) The vmexit path (take a look at vcpu_run), takes slots_lock in read-mode. This means that no other vcpu will be able to dirty a shadow translation (spte) in the meantime. So its safe. > but in kvm_vm_ioctl_set_memory_alias(): > > spin_unlock(&kvm->mmu_lock); > kvm_mmu_zap_all(kvm); > > it comes after inside kvm_mmu_zap_all(). Does it sound logical? Note that here it also takes slots_lock in write-mode, which blocks all other vcpus.