From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37763)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1SWgq5-0002r5-Ik
	for qemu-devel@nongnu.org; Tue, 22 May 2012 00:36:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1SWgq2-0000Ro-Kb
	for qemu-devel@nongnu.org; Tue, 22 May 2012 00:36:51 -0400
Received: from ozlabs.org ([203.10.76.45]:54680)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1SWgq2-0000RM-8p
	for qemu-devel@nongnu.org; Tue, 22 May 2012 00:36:50 -0400
From: Rusty Russell <rusty@rustcorp.com.au>
In-Reply-To: <1337637497.2779.114.camel@pasglop>
References: <1337565405.2458.12.camel@pasglop> <4FB9F89A.90702@redhat.com>
	<20120521083132.GI4674@redhat.com>
	<1337590688.2779.37.camel@pasglop>
	<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>
Date: Tue, 22 May 2012 13:49:47 +0930
Message-ID: <8762bo3l0c.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory
	access function
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>, David Gibson <david@gibson.dropbear.id.au>

On Tue, 22 May 2012 07:58:17 +1000, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Mon, 2012-05-21 at 15:18 +0300, Michael S. Tsirkin wrote:
> > But I can also live with a global flag "latest_dma_read"
> > and on read we could do
> > 	if (unlikely(latest_dma_read))
> > 		smp_mb();
> > 
> > if you really insist on it
> > though I do think it's inelegant.
> 
> Again, why do you object on simply making the default accessors fully
> ordered ? Do you think it will be a measurable different in most cases ?
> 
> Shouldn't we measure it first ?

Yes.  It seems clear to me that qemu's default DMA operations should be
strictly ordered.  It's just far easier to get right.

After that, we can get tricky with conditional barriers, and we can get
tricky with using special unordered variants in critical drivers, but I
really don't want to be chasing subtle SMP ordering problems in
production.

If you're working on ARM or PPC, "it works for x86" makes it *worse*,
not better, since you have fewer users to find bugs.

Cheers,
Rusty.