[Xen-devel] RE: co-assignment needs for PCI devices

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

Jan Beulich wrote:
> c/s 18046 adds the requirement to co-assign PCI devices behind
> bridges/ PCIe functions on the same device when the (perhaps
> individual) device/ function intended to be assigned doesn't support
> FLR and doesn't sit on bus 0. For non-IOMMU environments (which are
> insecure anyway) this 
> could be considered a regression, since passing through individual
> devices/ functions didn't know such a restriction earlier.
Yes, this may not proper for the non-IOMMU case. I planned to fix it, but 
haven't done that yet... I'd appreciate anybody who can help to do that. :-)
We need to consider IOMMU case, non-IOMMU case and 'hybrid case'(namely, the 
xen parameter iommu=on,no-pv).

> Also, being not really knowledgeable about all the differences between
> PCIe and PCI, I'd appreciate some clarification on why on PCIe it is
> possible and correct to do a secondary bus reset when targeting just
> the (PCIe) functions of a single device - to me this seems to imply
> that there's a one-device-per-non-root-bus restriction there.
According to VT-d spec (section 3.6.1: Identifying Origination of DMA 
Requests), PCI devices behind the same uppermost PCI/PCI-X bridge must be 
co-assigned to the same guest. PCIe devices have not such a constraint.

FLR (Functional Level Reset) is used to quiesce an assigned device when we 
destroy a guest or we detach the device from the guest. If a PCIe device has no 
standard FLR capability, we'll try to use SecondaryBusReset as a way to do FLR. 
Unluckily,  SecondaryBusReset resets all the devices behind the bridge, so for 
a multi-function PCIe device without FLR capability, we require they have to be 
co-assigned to the same guest --  certainly this is only for iommu case and for 
non-iommu case this requirement may be not proper and we shoud fix it...

Thanks,
-- Dexuan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel