Re: [Qemu-devel] [PATCH 10/13] iommu: Introduce IOMMU emulation infrastructure

[David Gibson <david@gibson.dropbear.id.au>]

On Tue, Mar 13, 2012 at 02:56:47PM +0100, Alexander Graf wrote:
> 
> On 13.03.2012, at 06:07, David Gibson wrote:
> 
> > On Fri, Mar 09, 2012 at 11:23:01AM +0100, Paolo Bonzini wrote:
> >> Il 09/03/2012 06:01, David Gibson ha scritto:
> >>> This patch adds the basic infrastructure necessary to emulate an IOMMU
> >>> visible to the guest.  The DMAContext structure is extended with
> >>> information and a callback describing the translation, and the various
> >>> DMA functions used by devices will now perform IOMMU translation using
> >>> this callback.
> >>> 
> >>> Cc: Michael S. Tsirkin <mst@redhat.com>
> >>> Cc: Richard Henderson <rth@twiddle.net>
> >>> 
> >>> Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
> >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>> ---
> >>> configure     |   12 ++++
> >>> dma-helpers.c |  191 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>> dma.h         |  125 +++++++++++++++++++++++++++++++-------
> >>> 3 files changed, 306 insertions(+), 22 deletions(-)
> >>> 
> >>> diff --git a/configure b/configure
> >>> index a5eb832..e6fba2f 100755
> >>> --- a/configure
> >>> +++ b/configure
> >>> @@ -138,6 +138,7 @@ linux_aio=""
> >>> cap_ng=""
> >>> attr=""
> >>> libattr=""
> >>> +iommu="yes"
> >>> xfs=""
> >>> 
> >>> vhost_net="no"
> >>> @@ -784,6 +785,10 @@ for opt do
> >>>   ;;
> >>>   --enable-vhost-net) vhost_net="yes"
> >>>   ;;
> >>> +  --enable-iommu) iommu="yes"
> >>> +  ;;
> >>> +  --disable-iommu) iommu="no"
> >>> +  ;;
> >> 
> >> This need not be a configure option.  Just enable it, or it will
> >> bitrot.
> > 
> > I did wonder about that.  I'd like to hear that suggested by more than
> > one person before I unconditionally add code which will impose an
> > overhead on all emulated DMAs.
> 
> Maybe make it a target option? That way targets that want and need
> an IOMMU can compile the code in, while the others don't see
> performance hits. That would of course mean that we'd still have
> conditional code paths, but at least they wouldn't bitrot, as
> building multiple targets means you'd build both paths.

Heh, yeah, so I tried that way back.  It's problematic, unfortunately,
as it would require pulling a number of things out of libhw and back
into target dependent code.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson