On 10/5/26 15:20, Fred Griffoul wrote:
On 10/5/26 Christian König wrote:
Well filling page tables by the importer is an absolutely clear NO-GO for the DMA-buf design, we have gotten down that path already and it took us years to remove this functionality again.
Understood, thanks for the quick and clear answers on this patch and on patch 3.
The problem you are facing here is that dma_buf_mmap() doesn't work because you don't have a VMA.
Right: the memory has no struct page and is deliberately not mapped in the host, so there is no VMA to hand to KVM.
I'll post a new version of this series. It drops get_phys(), the ranged invalidation and the guest_memfd dma-buf import (patches 2-5), and it does not touch drivers/dma-buf, as you suggested in the PAL discussion:
https://lore.kernel.org/all/c413710b-4c28-4ed8-88ec-aeb8c4482011@amd.com/
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.
Regards, Christian.
Thanks, Fred