From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrea Arcangeli <andrea@qumranet.com>
Subject: [ofa-general] Re: [patch] my mmu notifiers
Date: Wed, 20 Feb 2008 02:09:41 +0100
Message-ID: <20080220010941.GR7128@v2.random>
References: <20080219084357.GA22249@wotan.suse.de>
	<20080219135851.GI7128@v2.random>
	<20080219231157.GC18912@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: steiner@sgi.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-mm@kvack.org, Izik Eidus <izike@qumranet.com>,
	Kanoj Sarcar <kanojsarcar@yahoo.com>,
	Roland Dreier <rdreier@cisco.com>, linux-kernel@vger.kernel.org,
	Avi Kivity <avi@qumranet.com>, kvm-devel@lists.sourceforge.net,
	daniel.blueman@quadrics.com, Robin Holt <holt@sgi.com>,
	general@lists.openfabrics.org, akpm@linux-foundation.org,
	Christoph Lameter <clameter@sgi.com>
To: Nick Piggin <npiggin@suse.de>
Return-path: <general-bounces@lists.openfabrics.org>
Content-Disposition: inline
In-Reply-To: <20080219231157.GC18912@wotan.suse.de>
List-Unsubscribe: <http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general>,
	<mailto:general-request@lists.openfabrics.org?subject=unsubscribe>
List-Archive: <http://lists.openfabrics.org/pipermail/general>
List-Post: <mailto:general@lists.openfabrics.org>
List-Help: <mailto:general-request@lists.openfabrics.org?subject=help>
List-Subscribe: <http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general>,
	<mailto:general-request@lists.openfabrics.org?subject=subscribe>
Sender: general-bounces@lists.openfabrics.org
Errors-To: general-bounces@lists.openfabrics.org
List-Id: kvm.vger.kernel.org

On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
> Sorry, I realise I still didn't get this through my head yet (and also
> have not seen your patch recently). So I don't know exactly what you
> are doing...

The last version was posted here:

http://marc.info/?l=kvm-devel&m=120321732521533&w=2

> But why does _anybody_ (why does Christoph's patches) need to invalidate
> when they are going to be more permissive? This should be done lazily by
> the driver, I would have thought.

This can be done lazily by the driver yes. The place where I've an
invalidate_pages in mprotect however can also become less permissive.
It's simpler to invalidate always and it's not guaranteed the
secondary mmu page fault is capable of refreshing the spte across a
writeprotect fault. In the future this can be changed to
mprotect_pages though, so no page fault will happen in the secondary
mmu.