On Wed, Nov 29, 2023 at 05:42:57PM +0000, Robin Murphy wrote: > Hi all, > > Prompted by Jason's proposal[1], here's a first step towards truly > unpicking the dma_configure vs. IOMMU mess. As I commented before, we > have an awful lot of accumulated cruft and technical debt here making > things more complicated than they need to be, and we already have hacks > on top of hacks trying to work around it, so polishing those hacks even > further is really not a desirable direction of travel. And I do know > they're hacks, because I wrote most of them and still remember enough of > the context of the time ;) I quite like this, I was also looking at getting rid of those other parameters. I wanted to take smaller steps because it is all pretty hairy. One thing that still concerns me is if the FW data restricts the valid IOVA window that really should be reflected into the reserved ranges and not just dumped into the struct device for use by the DMA API. Or, perhaps, viof/iommufd should be using the struct device data to generate some additional reserved ranges? Either way, I would like to see the dma_iommu and the rest of the subsystem agree on what the valid IOVA ranges actually are. Jason
