On Mon, Oct 05, 2026 at 04:53:34PM +0200, Christian König wrote: > > KVM gets its frames through the KVM-private guest_memfd provider > > interface from David's series. iommufd gets them through a private > > interface with the exporter, as it already does for vfio-pci. The new > > version adds a small registry in iommufd for that, which replaces the > > symbol_get() of the sample in David's series. The dma-buf is then only > > the handle and the existing revoke. > > Yeah that approach sounds totally sane to me. > > We have drivers which stuff all kind of resources, not just memory, > into a DMA-buf. That ranges from MMIO BARs to trigger FW operations > (doorbells) over full HW blocks (ordered appends, global wave sync > etc...) where two or more applications need to share which one is > used. > > That you then have a exporter private interface is for accessing > this is perfectly ok. > > The problem you are facing here is more that this is not limited to > one driver/module but multiple ones and you don't want module inter > dependencies because of the symbols. > > So symbol_get() is probably the right thing to do as long as we > don't have something like weak symbols or similar.
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. Jason
