On Wed, Sep 07, 2011 at 04:37:11PM -0400, Don Dutile wrote: > On 09/07/2011 03:44 PM, Greg KH wrote: >> Why are you pushing this down into the driver core? What other busses >> becides PCI use/need this? >> >> If you can have a different IOMMU driver on the same bus, then wouldn't >> this be a per-device thing instead of a per-bus thing? >> > And given the dma api takes a struct device *, it'd be more efficient > to be tied into the device structure. More efficient in what way? Currently no dma-api implementation uses the iommu-api directly. It is planned to change that, of course. But the dma-api implementation will use the iommu_map/iommu_unmap functions which get an iommu_domain parameter and no device structure. Thats why the domain structure keeps an iommu_ops pointer too. > Device structure would get iommu ops set by parent(bus); > if a bus (segment) doesn't provide a unique/different/layered IOMMU > then the parent bus, it inherits the parent's iommu-ops. > setting the iommu-ops in the root bus struct, seeds the iommu-ops > for the (PCI) tree. > > For intel & amd IOMMUs, in early pci (bios,root?) init, you would > seed the pci root busses with appropriate IOMMU support (based on > dmar/drhd & ivrs/ivhd data structures, respectively), and > then modify the PCI code to do the inheritence (PPB code inherits > unless specific device driver for a given PPB vid-did loads a > different iommu-ops for that segment/branch). > > This would enable different types of IOMMUs for different devices > (or PCI segments, or branches of PCI trees) that are designed for > different tasks -- simple IOMMUs for legacy devices; complicated, io-page-faulting > IOMMUs for plug-in, high-end devices on virtualizing servers for PCI (SRIOV) endpoints. This only works for pci, but the iommu-api is not pci-only. > and as Greg indicates, is only relevant to PCI. We already have non-pci iommu drivers implementing the iommu-api. So this is certainly relevant outside pci too. Joerg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
