From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWhNV-00078y-0B for qemu-devel@nongnu.org; Tue, 22 May 2012 01:11:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWhNT-0000RU-Bs for qemu-devel@nongnu.org; Tue, 22 May 2012 01:11:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWhNT-0000RP-4C for qemu-devel@nongnu.org; Tue, 22 May 2012 01:11:23 -0400 Date: Tue, 22 May 2012 08:11:21 +0300 From: "Michael S. Tsirkin" Message-ID: <20120522051120.GA31936@redhat.com> References: <1337591230.2779.42.camel@pasglop> <1337591787.2779.48.camel@pasglop> <20120521093440.GK4674@redhat.com> <1337594003.2779.56.camel@pasglop> <20120521103101.GL4674@redhat.com> <1337600758.2779.90.camel@pasglop> <20120521121824.GA8666@redhat.com> <1337637497.2779.114.camel@pasglop> <20120521222243.GI17031@redhat.com> <1337640972.2779.127.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337640972.2779.127.camel@pasglop> Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory access function List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Paolo Bonzini , qemu-devel@nongnu.org, Anthony Liguori , David Gibson On Tue, May 22, 2012 at 08:56:12AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2012-05-22 at 01:22 +0300, Michael S. Tsirkin wrote: > > > Again, from which originator ? From a given initiator, nothing > > bypasses > > > anything, so the right thing to do here is a full mb(). However, I > > > suspect what you are talking about here is read -responses- not > > > bypassing writes in the direction of the response (ie, the > > "flushing" > > > semantic of reads) which is a different matter. > > > > No. My spec says: > > A3, A4 > > A Posted Request must be able to pass Non-Posted Requests to avoid > > deadlocks. > > Right, a read + write can become write + read at the target, I forgot > about that, or you can deadlock due to the flush semantics, but a write > + read must remain in order or am I missing something ? Exactly. > And write + read afaik is typically the one that x86 can re-order > without a barrier isn't it ? AFAIK without a barrier, x86 can reorder them however you initiate them. -- MST