From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWbLF-0002hv-Ue for qemu-devel@nongnu.org; Mon, 21 May 2012 18:44:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWbLE-0003uC-9S for qemu-devel@nongnu.org; Mon, 21 May 2012 18:44:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWbLE-0003to-1U for qemu-devel@nongnu.org; Mon, 21 May 2012 18:44:40 -0400 Date: Tue, 22 May 2012 01:44:37 +0300 From: "Michael S. Tsirkin" Message-ID: <20120521224436.GL17031@redhat.com> References: <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> <4FBAC22A.5010708@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FBAC22A.5010708@codemonkey.ws> 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: Anthony Liguori Cc: David Gibson , qemu-devel@nongnu.org, Paolo Bonzini On Mon, May 21, 2012 at 05:31:06PM -0500, Anthony Liguori wrote: > 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. I think what's called for is what Ben proposed: track last transaction and use the appropriate 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 OK. Just not another level of indirect function callbacks please. Make it a library so each bus can do the right thing. There are not so many buses. -- MST