[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 13/13] iommu: Add a memory barrier to DMA RW fun

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 13/13] iommu: Add a memory barrier to DMA RW function
Date: Mon, 14 May 2012 19:52:15 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/09/2012 11:49 PM, Benjamin Herrenschmidt wrote:
From: David Gibson<address@hidden>

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<address@hidden>
Signed-off-by: Benjamin Herrenschmidt<address@hidden>
  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?


Anthony Liguori

      return 0;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]