From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nocor-0006R3-2n for qemu-devel@nongnu.org; Mon, 08 Mar 2010 08:16:25 -0500 Received: from [199.232.76.173] (port=55944 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nocop-0006Pv-4Z for qemu-devel@nongnu.org; Mon, 08 Mar 2010 08:16:23 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nocoo-0001mE-9r for qemu-devel@nongnu.org; Mon, 08 Mar 2010 08:16:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41360) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nocon-0001m0-RV for qemu-devel@nongnu.org; Mon, 08 Mar 2010 08:16:22 -0500 Message-ID: <4B94F89B.3060504@redhat.com> Date: Mon, 08 Mar 2010 15:16:11 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device 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> In-Reply-To: <201003081303.45179.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 On 03/08/2010 03:03 PM, 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. > Ah yes. For cross tcg environments you can map the memory using mmio callbacks instead of directly, and issue the appropriate barriers there. -- error compiling committee.c: too many arguments to function