From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 2/2] kvm: ppc: booke: check range page invalidation progress on page setup Date: Mon, 07 Oct 2013 14:04:47 +0200 Message-ID: <5252A35F.1000502@redhat.com> References: <1375869826-17509-1-git-send-email-Bharat.Bhushan@freescale.com> <1375869826-17509-3-git-send-email-Bharat.Bhushan@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bharat Bhushan , Paul Mackerras , Scott Wood , kvm-ppc@vger.kernel.org, "kvm@vger.kernel.org mailing list" , Bharat Bhushan , Gleb Natapov To: Alexander Graf Return-path: Received: from mail-qa0-f41.google.com ([209.85.216.41]:35362 "EHLO mail-qa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755791Ab3JGMEy (ORCPT ); Mon, 7 Oct 2013 08:04:54 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Il 04/10/2013 15:38, Alexander Graf ha scritto: > > On 07.08.2013, at 12:03, Bharat Bhushan wrote: > >> When the MM code is invalidating a range of pages, it calls the KVM >> kvm_mmu_notifier_invalidate_range_start() notifier function, which calls >> kvm_unmap_hva_range(), which arranges to flush all the TLBs for guest pages. >> However, the Linux PTEs for the range being flushed are still valid at >> that point. We are not supposed to establish any new references to pages >> in the range until the ...range_end() notifier gets called. >> The PPC-specific KVM code doesn't get any explicit notification of that; >> instead, we are supposed to use mmu_notifier_retry() to test whether we >> are or have been inside a range flush notifier pair while we have been >> referencing a page. >> >> This patch calls the mmu_notifier_retry() while mapping the guest >> page to ensure we are not referencing a page when in range invalidation. >> >> This call is inside a region locked with kvm->mmu_lock, which is the >> same lock that is called by the KVM MMU notifier functions, thus >> ensuring that no new notification can proceed while we are in the >> locked region. >> >> Signed-off-by: Bharat Bhushan > > Acked-by: Alexander Graf > > Gleb, Paolo, please queue for 3.12 directly. Here is the backport. The second hunk has a nontrivial conflict, so someone please give their {Tested,Reviewed,Compiled}-by. Paolo diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c index 1c6a9d7..c65593a 100644 --- a/arch/powerpc/kvm/e500_mmu_host.c +++ b/arch/powerpc/kvm/e500_mmu_host.c @@ -332,6 +332,13 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, unsigned long hva; int pfnmap = 0; int tsize = BOOK3E_PAGESZ_4K; + int ret = 0; + unsigned long mmu_seq; + struct kvm *kvm = vcpu_e500->vcpu.kvm; + + /* used to check for invalidations in progress */ + mmu_seq = kvm->mmu_notifier_seq; + smp_rmb(); /* * Translate guest physical to true physical, acquiring @@ -449,6 +456,12 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, gvaddr &= ~((tsize_pages << PAGE_SHIFT) - 1); } + spin_lock(&kvm->mmu_lock); + if (mmu_notifier_retry(kvm, mmu_seq)) { + ret = -EAGAIN; + goto out; + } + kvmppc_e500_ref_setup(ref, gtlbe, pfn); kvmppc_e500_setup_stlbe(&vcpu_e500->vcpu, gtlbe, tsize, @@ -457,10 +470,13 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, /* Clear i-cache for new pages */ kvmppc_mmu_flush_icache(pfn); +out: + spin_unlock(&kvm->mmu_lock); + /* Drop refcount on page, so that mmu notifiers can clear it */ kvm_release_pfn_clean(pfn); - return 0; + return ret; } /* XXX only map the one-one case, for now use TLB0 */