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'? We could even have a new device hotplugged after the assignment has been done. -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation -- 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
