From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoS2T-0003IV-FK for qemu-devel@nongnu.org; Sun, 07 Mar 2010 20:45:45 -0500 Received: from [199.232.76.173] (port=48720 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoS2S-0003IN-4r for qemu-devel@nongnu.org; Sun, 07 Mar 2010 20:45:44 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NoS2Q-0003kW-QO for qemu-devel@nongnu.org; Sun, 07 Mar 2010 20:45:43 -0500 Received: from mail2.shareable.org ([80.68.89.115]:35995) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NoS2Q-0003k4-GJ for qemu-devel@nongnu.org; Sun, 07 Mar 2010 20:45:42 -0500 Date: Mon, 8 Mar 2010 01:45:37 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Message-ID: <20100308014537.GA24024@shareable.org> References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <1267833161-25267-2-git-send-email-cam@cs.ualberta.ca> <201003072254.00040.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003072254.00040.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 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. Yes. Guest-observable behaviour is likely to be quite different on different hosts, expecially beteen x86 and non-x86 hosts, which is not good at all for emulation. Memory barriers performed by the guest would help, but would not remove the fact that behaviour would vary beteen different host types if a guest doesn't call them. I.e. you could accidentally have some guests working fine for years on x86 hosts, which gain subtle memory corruption as soon as you run them on a different host. This is acceptable when recompiling code for different architectures, but it's asking for trouble with binary guest images which aren't supposed to depend on host architecture. 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. -- Jamie