On Mon, Oct 12, 2026 at 11:46:16AM -0300, Jason Gunthorpe wrote: > I don't want to keep expanding this hack in iommufd. If dmabuf is to > be used then dmabuf needs to provide a pluggable way to fill the > iommu_domain that many exporters can plug into. I don't want to > hardwire every exporter into iommufd, that makes no sense. > > The existing arrangement is to motivate solving this problem > generically, not something to be expanded on.
Agreed. The iommufd registry I mentioned above was never posted, and I have dropped it. The series I posted since takes another route, without dma-buf: https://lore.kernel.org/all/[email protected]/ It adds a small interface in mm for drivers that own memory. Such a driver hands out files, and for each page of a file it tells the caller which frame backs it. iommufd maps the file with IOMMU_IOAS_MAP_FILE and builds the iommu_domain itself, and the driver revokes a range when it changes. So iommufd never knows which driver it is talking to, and there is no symbol_get(). guest_memfd uses the same files for the guest. The iommufd part is patch 5: https://lore.kernel.org/all/[email protected]/ The iommufd part is mainly there to show the interface, and it needs more work. Its revoke unmaps and then remaps, so a device can hit a hole. I would rebuild it on the REPLACE operation David discussed with you at LPC, with the scratch page as a quirk on the IOAS. Is this the kind of generic interface you had in mind, or would you rather have it hang off dma-buf? Thanks, Fred
