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

[Alexander Graf]

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 <address@hidden>
>>>>> Cc: Richard Henderson <address@hidden>
>>>>> 
>>>>> Signed-off-by: Eduard - Gabriel Munteanu <address@hidden>
>>>>> Signed-off-by: David Gibson <address@hidden>
>>>>> ---
>>>>> 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