From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:50269)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1SU6J8-0002PC-Nd
	for qemu-devel@nongnu.org; Mon, 14 May 2012 21:12:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1SU6J7-0002Qv-2L
	for qemu-devel@nongnu.org; Mon, 14 May 2012 21:12:10 -0400
Received: from gate.crashing.org ([63.228.1.57]:39271)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1SU6J6-0002Qj-Pt
	for qemu-devel@nongnu.org; Mon, 14 May 2012 21:12:08 -0400
Message-ID: <1337044314.6727.23.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 15 May 2012 11:11:54 +1000
In-Reply-To: <4FB1A8BF.7060503@codemonkey.ws>
References: <1336625347-10169-1-git-send-email-benh@kernel.crashing.org>
	<1336625347-10169-14-git-send-email-benh@kernel.crashing.org>
	<4FB1A8BF.7060503@codemonkey.ws>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 13/13] iommu: Add a memory barrier to DMA
 RW 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: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, David Gibson <david@gibson.dropbear.id.au>

On Mon, 2012-05-14 at 19:52 -0500, Anthony Liguori wrote:

> >
> > diff --git a/dma-helpers.c b/dma-helpers.c
> > index 36fa963..4350cdf 100644
> > --- a/dma-helpers.c
> > +++ b/dma-helpers.c
> > @@ -312,6 +312,9 @@ int iommu_dma_memory_rw(DMAContext *dma, dma_addr_t addr,
> >           buf += plen;
> >       }
> >
> > +    /* HACK: full memory barrier here */
> > +    __sync_synchronize();
> 
> I thought you were going to limit this to the TCE iommu?

I can I suppose but technically speaking, this isn't an attribute of the
iommu... in fact, from a model standpoint, it should be in the pci_*
accessors since PCI transactions are ordered (at least to some extent,
let's not get into relaxed ordering etc... at this stage).

It was just easier to stick it in the above function for now, which
handles all known cases... I'm happy to move it to the TCE backend if
you prefer for now but I can see that problem hitting other
architectures such as ARM or even on powerpc, hitting emulated PCI on
Alex "usermode" KVM using the Mac99 machine model which doesn't use TCEs
etc....

Cheers,
Ben.