Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756023AbYANUDB (ORCPT ); Mon, 14 Jan 2008 15:03:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755852AbYANUCo (ORCPT ); Mon, 14 Jan 2008 15:02:44 -0500 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:54471 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755856AbYANUCn (ORCPT ); Mon, 14 Jan 2008 15:02:43 -0500 Date: Mon, 14 Jan 2008 12:02:42 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Andrea Arcangeli cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm-devel@lists.sourceforge.net, Avi Kivity , Izik Eidus , daniel.blueman@quadrics.com, holt@sgi.com, steiner@sgi.com, Andrew Morton , Hugh Dickins , Nick Piggin , Benjamin Herrenschmidt Subject: Re: [PATCH] mmu notifiers #v2 In-Reply-To: <20080113162418.GE8736@v2.random> Message-ID: References: <20080113162418.GE8736@v2.random> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2223 Lines: 54 On Sun, 13 Jan 2008, Andrea Arcangeli wrote: > About the locking perhaps I'm underestimating it, but by following the > TLB flushing analogy, by simply clearing the shadow ptes (with kvm > mmu_lock spinlock to avoid racing with other vcpu spte accesses of > course) and flushing the shadow-pte after clearing the main linux pte, > it should be enough to serialize against shadow-pte page faults that > would call into get_user_pages. Flushing the host TLB before or after > the shadow-ptes shouldn't matter. Hmmm... In most of the callsites we hold a writelock on mmap_sem right? > Comments welcome... especially from SGI/IBM/Quadrics and all other > potential users of this functionality. > There are also certain details I'm uncertain about, like passing 'mm' > to the lowlevel methods, my KVM usage of the invalidate_page() > notifier for example only uses 'mm' for a BUG_ON for example: Passing mm is fine as long as mmap_sem is held. > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -86,6 +86,7 @@ do { \ > pte_t __pte; \ > __pte = ptep_get_and_clear((__vma)->vm_mm, __address, __ptep); \ > flush_tlb_page(__vma, __address); \ > + mmu_notifier(invalidate_page, (__vma)->vm_mm, __address); \ > __pte; \ > }) > #endif Hmmm... this is ptep_clear_flush? What about the other uses of flush_tlb_page in asm-generic/pgtable.h and related uses in arch code? (would help if your patches would mention the function name in the diff headers) > +#define mmu_notifier(function, mm, args...) \ > + do { \ > + struct mmu_notifier *__mn; \ > + struct hlist_node *__n; \ > + \ > + hlist_for_each_entry(__mn, __n, &(mm)->mmu_notifier, hlist) \ > + if (__mn->ops->function) \ > + __mn->ops->function(__mn, mm, args); \ > + } while (0) Does this have to be inline? ptep_clear_flush will become quite big -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/