Generic DT bindings for PCI IOMMUs and ARM SMMU
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v7 Latest posting 3/30 of 22 patches 0 repliesNew
- v7 posting 2/30 of 22 patches 0 repliesSuperseded
- v7 posting 1/30 of 22 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v6 | 0 of 20 patches | 0 replies | Superseded |
Patches in v7 posting 3/3 No applies recorded yet
None of the 22 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v7 yet.
Cover letter [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
Quoted 18 lines · Robin Murphy
Quoted 8 lines · Will Deacon
Quoted 7 lines · Auger Eric
Quoted 5 lines · Robin Murphy
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
For Seattle, perhaps, but that's quite a big generalisation. If we're going to add an option, I'd much rather add something with some flexibility, rather than end up supporting both "disable_dma_domains" and "reserved_s2_contexts" in the long run.
Quoted 3 lines
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?
There's two things in this example:
(1) If other SMMUs only have 2 contexts, then they reserve both and warn
(2) If some SMMUs want DMA ops and others don't, then you have an issue with *any* sort of cmdline option to control this
Will