Messages in this thread | | | Date | Thu, 7 Nov 2019 10:13:59 +0100 | From | Jean-Philippe Brucker <> | Subject | Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers |
| |
On Wed, Nov 06, 2019 at 10:11:55PM -0800, Saravana Kannan wrote: > > Right, in short the fundamental problem is that of_iommu_configure() now > > does the wrong thing. Deferring probe of the entire host bridge/root > > complex based on "iommu-map" would indeed happen to solve the problem by > > brute force, I think, but could lead to a dependency cycle for PCI-based > > IOMMUs as Jean points out. > > Sorry for the late reply. Got caught up on other work. > > I didn't think the SMMU itself was PCI based in the example Jean gave. > I thought it just happened to be the case where the SMMU probes after > the pcieport but before the other children. If the SMMU itself is a > child of the pcieport, how can it be required for the parent to > function? How will suspend/resume even work?! I feel like I'm missing > some context wrt to PCI that everyone else seems to know (which isn't > surprising).
The Arm SMMU isn't PCI based, it always appears as an independent MMIO device. John's problem is something different if I understand correctly, where the probe order between pcieport and endpoint shouldn't affect the IOMMU grouping, but currently does.
Two other IOMMU models are PCI based, though, AMD IOMMU and virtio-iommu (which is a purely virtual device). In theory they can have their programming interface anywhere in the PCI config space, but to ensure proper software support they should be at the top of the PCI hierarchy. AMD strongly recommends that the IOMMU is a root-complex device (4.5 - Software and Platform Firmware Implementation Issues). Within a PCIe system the IOMMU would have to be a Root Complex integrated Endpoint, not be a child of a root port.
Thanks, Jean
| |