On 19/09/16 13:24, Will Deacon wrote: > On Mon, Sep 19, 2016 at 02:13:45PM +0200, Auger Eric wrote: >> On 16/09/2016 18:18, Robin Murphy wrote: >>> What I probably will do, though, since we have the functionality in >>> place for the sake of the old binding, and I think there are other folks >>> who want PCI iommu-map support but would prefer not to bother with DMA >>> ops on the host, is add a command-line option to disable DMA domains >>> even for the generic bindings. >> >> Yes this would be a good thing I think. This series has an important >> impact on platforms which do not have smmu v3, where contexts are scarce >> HW resources. > > Rather than disabling DMA domains entirely, we could specify a number > of contexts to reserve for other use (e.g. VFIO). It's a pity that these > options are global for the system, as opposed to per SMMU instance, > but I can't see a good way around that. The problem with that approach is that due to bus traversal order you'd typically end up with the even-more-limited number of non-reserved contexts getting consumed by bridges that are unlikely to ever actually use their DMA ops, so you end up barely any better off than just not doing DMA ops at all, which we already have the code for. And yeah, if you had, say, "arm-smmu.reserved_s2_contexts=4", for the benefit of your PCI SMMU, what do the SMMUs in front of your other platform devices with only 2 contexts (and which only want DMA ops) do? Robin. > > Will > _______________________________________________ > iommu mailing list > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/iommu > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
