From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NpDgn-00068m-CK
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 23:38:33 -0500
Received: from [199.232.76.173] (port=50899 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NpDgn-00068a-20
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 23:38:33 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <camm@ualberta.ca>) id 1NpDgl-0003mG-R8
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 23:38:32 -0500
Received: from mail-iw0-f176.google.com ([209.85.223.176]:57099)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <camm@ualberta.ca>) id 1NpDgl-0003mC-Ia
	for qemu-devel@nongnu.org; Tue, 09 Mar 2010 23:38:31 -0500
Received: by iwn6 with SMTP id 6so4458149iwn.4
	for <qemu-devel@nongnu.org>; Tue, 09 Mar 2010 20:38:30 -0800 (PST)
MIME-Version: 1.0
Sender: camm@ualberta.ca
In-Reply-To: <201003100003.38612.paul@codesourcery.com>
References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca>
	<201003081303.45179.paul@codesourcery.com>
	<20100309201243.GH11042@shareable.org>
	<201003100003.38612.paul@codesourcery.com>
Date: Tue, 9 Mar 2010 21:38:29 -0700
Message-ID: <8286e4ee1003092038v2eaed1f4i25a12f09cb69ce31@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device
From: Cam Macdonell <cam@cs.ualberta.ca>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Avi Kivity <avi@redhat.com>

On Tue, Mar 9, 2010 at 5:03 PM, Paul Brook <paul@codesourcery.com> wrote:
>> > In a cross environment that becomes extremely hairy. =A0For example th=
e 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.
>
> As of March 2009[1] Intel guarantees that memory reads occur in order (th=
ey
> may only be reordered relative to writes). It appears AMD do not provide =
this
> guarantee, which could be an interesting problem for heterogeneous migrat=
ion..
>
> Paul
>
> [*] The most recent docs I have handy. Up to and including Core-2 Duo.
>

Interesting, but what ordering would cause problems that AMD would do
but Intel wouldn't?  Wouldn't that ordering cause the same problems
for POSIX shared memory in general (regardless of Qemu) on AMD?

I think shared memory breaks migration anyway.

Cam