Re: [PATCH] VT-d: fix PCI device detach from virtual machine

[Weidong Han <weidong.han@intel.com>]

David Woodhouse wrote:
> On Thu, 2010-06-17 at 11:35 +0800, Weidong Han wrote:
>   
>> David Woodhouse wrote:
>>     
>>> So why do we bother setting up a context in the IOMMU for the device
>>> itself, when no DMA will ever appear to come from this device? And
>>>   
>>>       
>> if the device is behind PCI Express-to-PCI/PCI-X bridge, the source-id 
>> may be the device bdf or the source-id provided by the bridge. so it
>> needs to map the device itself.
>>     
>
> Ah, that makes some sense, and matches what Jörg said about the AMD
> IOMMU spec. Thanks.
>
>   
>>> likewise why do we bother setting up a context for intermediate PCI
>>> bridges?
>>>   
>>>       
>> I'm not sure if the intermediate PCI bridges are necessary. need to 
>> check PCI spec.
>>     
>
> FWIW, the AMD IOMMU doesn't do this; it only sets up the mapping for the
> original device and for its 'proxy'.
>
>   
>>> Why not just jump straight to the 'DMA proxy' device, and use that
>>> _only_?
>>>   
>>>       
>> What's the 'DMA proxy' device? is it the upstream pcie-to-pci bridge?
>>     
>
> Yes. Or, in the case of a certain buggy Ricoh multi-function device, it
> is function zero -- all other functions do their DMA as if it came from
> function zero.
>
> This is why I'm looking at whether we need the whole tree-walking thing,
> or whether we can just have a single 'proxy' device (or 'alias' as it's
> called in the AMD code).
>
>   
>> all the device behind a pcie-to-pci bridge must be co-assigned to a 
>> single domain. So it also require users to detach them together.
>>     
>
> Do we even _have_ an API for KVM to assign multiple devices at the same
> time? Or an API for KVM to _determine_ which devices are behind the same
> 'proxy'?
>   
No. I think it's better to add some checks in management tool (e.g. 
libvirt) to determine if the devices can be assigned or not before 
device assignment, such as all devices behind same 'proxy' are 
co-assigned (checking command line), and devices can be reset (FLR, 
secondary bus reset, D0->D3 etc.) I think libvirt already has these 
checks for device assignment.


> We could even have a new device hotplugged after the assignment has been
> done.
>   

yes, but for these legacy devices, they only can be assigned and 
de-assigned at the same time.

Regards,
Weidong