From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Np4fW-0006MJ-9j
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 14:00:38 -0500
Received: from [199.232.76.173] (port=52499 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Np4fV-0006Kf-I7
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 14:00:37 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <jamie@shareable.org>) id 1Np4fU-0000yt-B1
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 14:00:37 -0500
Received: from mail2.shareable.org ([80.68.89.115]:48281)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1Np4fU-0000yf-2h
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 14:00:36 -0500
Date: Tue, 9 Mar 2010 19:00:30 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device
Message-ID: <20100309190030.GB11042@shareable.org>
References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca>
	<201003072254.00040.paul@codesourcery.com>
	<20100308014537.GA24024@shareable.org>
	<201003081304.45862.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201003081304.45862.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: Cam Macdonell <cam@cs.ualberta.ca>, qemu-devel@nongnu.org, kvm@vger.kernel.org

Paul Brook wrote:
> > However, coherence could be made host-type-independent by the host
> > mapping and unampping pages, so that each page is only mapped into one
> > guest (or guest CPU) at a time.  Just like some clustering filesystems
> > do to maintain coherence.
> 
> You're assuming that a TLB flush implies a write barrier, and a TLB miss 
> implies a read barrier.  I'd be surprised if this were true in general.

The host driver itself can issue full barriers at the same time as it
maps pages on TLB miss, and would probably have to interrupt the
guest's SMP KVM threads to insert a full barrier when broadcasting a
TLB flush on unmap.

-- Jamie