[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: co-assignment needs for PCI devices
>>> "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> 31.03.09 09:48 >>> >Jan Beulich wrote: >> 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... But - for the sake of my education, if you forgive - you didn't answer whether there is a one-device-per-secondary-bus restriction on PCIe... Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |