From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np5nM-0007iD-PE for qemu-devel@nongnu.org; Tue, 09 Mar 2010 15:12:48 -0500 Received: from [199.232.76.173] (port=42818 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np5nM-0007hM-0a for qemu-devel@nongnu.org; Tue, 09 Mar 2010 15:12:48 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np5nK-00009b-QY for qemu-devel@nongnu.org; Tue, 09 Mar 2010 15:12:47 -0500 Received: from mail2.shareable.org ([80.68.89.115]:53870) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Np5nK-00009J-Ds for qemu-devel@nongnu.org; Tue, 09 Mar 2010 15:12:46 -0500 Date: Tue, 9 Mar 2010 20:12:43 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Message-ID: <20100309201243.GH11042@shareable.org> References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <201003072254.00040.paul@codesourcery.com> <4B94C8CD.2030808@redhat.com> <201003081303.45179.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003081303.45179.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Cam Macdonell , qemu-devel@nongnu.org, kvm@vger.kernel.org, Avi Kivity Paul Brook wrote: > > On 03/08/2010 12:53 AM, Paul Brook wrote: > > >> Support an inter-vm shared memory device that maps a shared-memory > > >> object as a PCI device in the guest. This patch also supports > > >> interrupts between guest by communicating over a unix domain socket. > > >> This patch applies to the qemu-kvm repository. > > > > > > No. All new devices should be fully qdev based. > > > > > > I suspect you've also ignored a load of coherency issues, especially when > > > not using KVM. As soon as you have shared memory in more than one host > > > thread/process you have to worry about memory barriers. > > > > Shouldn't it be sufficient to require the guest to issue barriers (and > > to ensure tcg honours the barriers, if someone wants this with tcg)?. > > In a cross environment that becomes extremely hairy. For example the x86 > architecture effectively has an implicit write barrier before every store, and > an implicit read barrier before every load. Btw, x86 doesn't have any implicit barriers due to ordinary loads. Only stores and atomics have implicit barriers, afaik. -- Jamie