Re: [PATCH] [RESEND] VT-d: Support multiple device assignment to one guest

[Avi Kivity <avi@redhat.com>]

Han, Weidong wrote:
>>
>> There is a missed optimization here.  Suppose we have two devices each
>> under a different iommu.  With the patch, each will be in a different
>> dmar_domain and so will have a different page table.  The amount of
>> memory used is doubled.
>>     
>
> You cannot let two devices each under a different iommu share one
> dmar_domain, becasue dmar_domain has a pointer to iommu.
>
>   

I don't want then to share dmar_domains (these are implementation
details anyway), just io page tables.


kvm ---> something (owns io page table) ---> dmar_domain (uses shared io
page table) ---> device

Even if we don't implement io page table sharing right away,
implementing the 'something' in the iommu api means we can later
impement sharing without changing the iommu/kvm interface.

> In fact, the exported APIs added for KVM VT-d also do
> create/map/attach/detach/free functions. Whereas these iommu APIs are
> more readable. 
>
>   


No; the existing iommu API talks about dmar domains and exposes the
existence of multiple iommus, so it is more complex.

> Because kvm VT-d usage is different with native usage, it's inevitable
> extend native VT-d code to support KVM VT-d (such as wrap dmar_domain).
> For devices under different iommus, they cannot share the same
> dmar_domain, thus they cannot share VT-d page table. If we want to
> handle this by iommu APIs, I suspect we need to change lots of native
> VT-d driver code.
>   

As mentioned above, we can start with implementing the API without
actual sharing (basically, your patch, but as an addition to the API
rather than a change to kvm); we can add io pagetable sharing later.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.