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 <anthony@codemonkey.ws>) 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 <anthony@codemonkey.ws>) 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 <qemu-devel@nongnu.org>; 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 <anthony@codemonkey.ws>
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: <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: Avi Kivity <avi@redhat.com>
Cc: Cam Macdonell <cam@cs.ualberta.ca>, Paul Brook <paul@codesourcery.com>, 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