From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SU5zx-0005YE-Db for qemu-devel@nongnu.org; Mon, 14 May 2012 20:52:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SU5zv-0007Eg-Ly for qemu-devel@nongnu.org; Mon, 14 May 2012 20:52:20 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:38261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SU5zv-0007Ea-GK for qemu-devel@nongnu.org; Mon, 14 May 2012 20:52:19 -0400 Received: by obbwd20 with SMTP id wd20so10013115obb.4 for ; Mon, 14 May 2012 17:52:18 -0700 (PDT) Message-ID: <4FB1A8BF.7060503@codemonkey.ws> Date: Mon, 14 May 2012 19:52:15 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1336625347-10169-1-git-send-email-benh@kernel.crashing.org> <1336625347-10169-14-git-send-email-benh@kernel.crashing.org> In-Reply-To: <1336625347-10169-14-git-send-email-benh@kernel.crashing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 13/13] iommu: Add a memory barrier to DMA RW function List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: qemu-devel@nongnu.org, David Gibson On 05/09/2012 11:49 PM, Benjamin Herrenschmidt wrote: > From: David Gibson > > The emulated devices can run simultaneously with the guest, so > we need to be careful with ordering of load and stores done by > them to the guest system memory, which need to be observed in > the right order by the guest operating system. > > The simplest way for now to address that is to stick a memory > barrier in the main DMA read/write function of the iommu layer, > this will make everything using that layer hopefully "just work". > > We don't emulate devices supporting the relaxed ordering PCIe > feature nor do we want to look at doing more fine grained > barriers for now as it could quickly become too complex and not > worth the cost. > > Note that this will not help devices using the map/unmap APIs, > those will need to use explicit barriers, similar to what > virtio does. > > Signed-off-by: David Gibson > Signed-off-by: Benjamin Herrenschmidt > --- > dma-helpers.c | 3 +++ > 1 file changed, 3 insertions(+) > > 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? Regards, Anthony Liguori > return 0; > } >