Avi Kivity wrote:
> Han, Weidong wrote:
>>> Oh, I see it now. Different devices may need to go under different
>>> iommus.
>>>
>>> This really feels like it should be handled by the iommu API. Users
>>> shouldn't need to bother with it.
>>>
>>
>> Why do you say it should be handled by iommu API?
>
> Because the logic of which iommu controls which device is only
> understood by iommu developers. Also, because this logic would be
> duplicated by anyone attempting to do the same thing.
>
> So it seems reasonable it should be implemented by the iommu API, not
> its users.
>
>> The direct way to
>> support multiple device assignment is keep a dmar_domain list for
>> each guest, each device corresponds to one dmar_domain. But this
>> will cost more memory because each dmar_domain has its own VT-d page
>> table. Our method lets the devices which are under smae iommu and
>> assigned to the same guest share the same VT-d page table.
>>
>
> If we devolve this to the iommu API, the same io page table can be
> shared by all iommus, so long as they all use the same page table
> format.
I don't understand how to handle this by iommu API. Let me explain my
thoughts more clearly:
VT-d spec says:
Context-entries programmed with the same domain identifier must
always reference the same address translation structure (through the ASR
field). Similarly, context-entries referencing the same address
translation structure must be programmed with the same domain id.
In native VT-d driver, dmar_domain is per device, and has its own VT-d
page table, which is dynamically setup before each DMA. So it is
impossible that the same VT-d page table is shared by all iommus.
Moveover different iommus in system may have different page table
levels. I think it's enough that iommu API tells us its iommu of a
device.
Whereas in KVM side, the same VT-d page table can be shared by the
devices which are under smae iommu and assigned to the same guest,
because all of the guest's memory are statically mapped in VT-d page
table. But it needs to wrap dmar_domain, this patch wraps it with a
reference count for multiple devices relate to same dmar_domain.
This patch already adds an API (intel_iommu_device_get_iommu()) in
intel-iommu.c, which returns its iommu of a device.
Regards,
Weidong
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
