On 13.03.2012, at 15:04, David Gibson wrote: > 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 <m...@redhat.com> >>>>> Cc: Richard Henderson <r...@twiddle.net> >>>>> >>>>> Signed-off-by: Eduard - Gabriel Munteanu <eduard.munte...@linux360.ro> >>>>> Signed-off-by: David Gibson <da...@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.
Hrm. How about measuring the performance overhead then? Maybe it's negligible? Alex
