From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NpIEr-0007Aw-2M for qemu-devel@nongnu.org; Wed, 10 Mar 2010 04:30:01 -0500 Received: from [199.232.76.173] (port=53476 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NpIEq-0007A2-Ex for qemu-devel@nongnu.org; Wed, 10 Mar 2010 04:30:00 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NpIEp-00070T-MP for qemu-devel@nongnu.org; Wed, 10 Mar 2010 04:30:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22146) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NpIEp-00070J-7p for qemu-devel@nongnu.org; Wed, 10 Mar 2010 04:29:59 -0500 Message-ID: <4B97668C.3060203@redhat.com> Date: Wed, 10 Mar 2010 11:29:48 +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> <201003081303.45179.paul@codesourcery.com> <20100309201243.GH11042@shareable.org> <201003100003.38612.paul@codesourcery.com> <8286e4ee1003092038v2eaed1f4i25a12f09cb69ce31@mail.gmail.com> In-Reply-To: <8286e4ee1003092038v2eaed1f4i25a12f09cb69ce31@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cam Macdonell Cc: Paul Brook , kvm@vger.kernel.org, qemu-devel@nongnu.org On 03/10/2010 06:38 AM, Cam Macdonell wrote: > On Tue, Mar 9, 2010 at 5:03 PM, Paul Brook wrote: > >>>> 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. >>>> >>> 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 (they >> may only be reordered relative to writes). It appears AMD do not provide this >> guarantee, which could be an interesting problem for heterogeneous migration.. >> >> 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? > If some code was written for the Intel guarantees it would break if migrated to AMD. Of course, it would also break if run on AMD in the first place. > I think shared memory breaks migration anyway. > Until someone implements distributed shared memory. -- error compiling committee.c: too many arguments to function