From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWb8F-00063P-9X for qemu-devel@nongnu.org; Mon, 21 May 2012 18:31:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWb8D-0007ZS-4X for qemu-devel@nongnu.org; Mon, 21 May 2012 18:31:14 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:45071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWb8C-0007Yy-UA for qemu-devel@nongnu.org; Mon, 21 May 2012 18:31:13 -0400 Received: by pbbro12 with SMTP id ro12so9161170pbb.4 for ; Mon, 21 May 2012 15:31:11 -0700 (PDT) Message-ID: <4FBAC22A.5010708@codemonkey.ws> Date: Mon, 21 May 2012 17:31:06 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1337213257.30558.22.camel@pasglop> <1337214293.30558.25.camel@pasglop> <4FB5F1FD.9020009@redhat.com> <1337329136.2513.7.camel@pasglop> <4FB60EFF.6070205@redhat.com> <1337379992.2513.17.camel@pasglop> <4FB74AB0.7090608@redhat.com> <1337549768.2458.0.camel@pasglop> <1337565405.2458.12.camel@pasglop> <4FB9F89A.90702@redhat.com> <20120521083132.GI4674@redhat.com> <4FBABF2D.2020200@codemonkey.ws> <1337639166.2779.117.camel@pasglop> In-Reply-To: <1337639166.2779.117.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory access functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Paolo Bonzini , David Gibson , qemu-devel@nongnu.org, "Michael S. Tsirkin" On 05/21/2012 05:26 PM, Benjamin Herrenschmidt wrote: > On Mon, 2012-05-21 at 17:18 -0500, Anthony Liguori wrote: >> But this isn't what this series is about. >> >> This series is only attempting to make sure that writes are ordered >> with respect >> to other writes in main memory. > > Actually, it applies to both reads and writes. They can't pass each > other either and that can be fairly important. That's fine but that's a detail of the bus. > It's in fact the main contention point because if it was only writes we > could just use wmb and be done with it (that's a nop on x86). > > Because we are trying to order everything (and specifically store > followed by a load), we need a full barrier which is more expensive on > x86. I think the thing to do is make the barrier implemented in the dma API and allow it to be overridden by the bus. The default implementation should be a full barrier. If we can establish that the bus guarantees a weaker ordering guarantee, a bus could override the default implementation and do something weaker. Regards, Anthony Liguori