On Wed, Jul 01, 2020 at 12:40:50AM -0700, Bjorn Andersson wrote: > On Wed 03 Jun 04:00 PDT 2020, Robin Murphy wrote: > > at that point I'm inclined to suggest we give up and stop trying to > > drive these things with arm-smmu. The XZR thing was bad enough, but if > > they're not even going to pretend to implement the architecture correctly > > then I'm not massively keen to continue tying the architectural driver in > > further knots if innocent things like CONFIG_IOMMU_DEFAULT_PASSTHROUGH are > > going to unexpectedly and catastrophically fail. We have qcom-iommu for > > hypervisor-mediated SMMUs, and this new hypervisor behaviour sounds to me > > more like "qcom-iommu++" with reassignable stream-to-context mappings, > > rather than a proper Arm SMMU emulation. > > > > I've been going through over and over, hoping to perhaps be able to > evolve qcom_iommu into a qcom-iommu++, but afaict the new hypervisor is > different enough that this isn't feasible. In particular, the platforms > using qcom_iommu relies entirely on the hypervisor to configure stream > mapping etc - and we can't even read most of the registers. > > On the other hand I agree with you that we're messing around quite a bit > with the arm-smmu driver, and I'm uncertain where we are on supporting > the various GPU features, so I'm adding Jordan to the thread. > > So, afaict we have the options of either shoehorning this too into the > arm-smmu driver or we essentially fork arm-smmu.c to create a > qcom-smmu.c. > > While I don't fancy the code duplication, it would allow us to revert > the Qualcomm quirks from arm-smmu and would unblock a number of > activities that we have depending on getting the SMMU enabled on various > platforms. We added the impl hooks to cater for implementation differences, so I'd still prefer to see this done as part of arm-smmu than introduce another almost-the-same-but-not-quite IOMMU driver that has the lifetime of a single SoC. Will
