From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NpPUn-0008WD-5e for qemu-devel@nongnu.org; Wed, 10 Mar 2010 12:14:57 -0500 Received: from [199.232.76.173] (port=46178 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NpPUm-0008VE-BG for qemu-devel@nongnu.org; Wed, 10 Mar 2010 12:14:56 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NpPUl-00049q-04 for qemu-devel@nongnu.org; Wed, 10 Mar 2010 12:14:56 -0500 Received: from qw-out-1920.google.com ([74.125.92.149]:49548) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NpPUP-000461-7b for qemu-devel@nongnu.org; Wed, 10 Mar 2010 12:14:54 -0500 Received: by qw-out-1920.google.com with SMTP id 5so2210431qwf.4 for ; Wed, 10 Mar 2010 09:14:01 -0800 (PST) Message-ID: <4B97D349.1030105@codemonkey.ws> Date: Wed, 10 Mar 2010 11:13:45 -0600 From: Anthony Liguori 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> <4B94F89B.3060504@redhat.com> <4B96C15A.2040600@codemonkey.ws> <4B97659E.2090603@redhat.com> In-Reply-To: <4B97659E.2090603@redhat.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: Avi Kivity Cc: Cam Macdonell , Paul Brook , kvm@vger.kernel.org, qemu-devel@nongnu.org On 03/10/2010 03:25 AM, Avi Kivity wrote: > On 03/09/2010 11:44 PM, Anthony Liguori wrote: >>> Ah yes. For cross tcg environments you can map the memory using >>> mmio callbacks instead of directly, and issue the appropriate >>> barriers there. >> >> >> Not good enough unless you want to severely restrict the use of >> shared memory within the guest. >> >> For instance, it's going to be useful to assume that you atomic >> instructions remain atomic. Crossing architecture boundaries here >> makes these assumptions invalid. A barrier is not enough. > > You could make the mmio callbacks flow to the shared memory server > over the unix-domain socket, which would then serialize them. Still > need to keep RMWs as single operations. When the host supports it, > implement the operation locally (you can't render cmpxchg16b on i386, > for example). But now you have a requirement that the shmem server runs in lock-step with the guest VCPU which has to happen for every single word of data transferred. You're much better off using a bulk-data transfer API that relaxes coherency requirements. IOW, shared memory doesn't make sense for TCG :-) Regards, Anthony Liguori