On Tue, Nov 18, 2025 at 03:37:41PM +0100, Christian König wrote:
Skimming over it my only concern is patch #6 which adds the helper to the common DMA-buf code and that in turn would need an in-deep review which I currently don't have time for.
I think you should trust Leon on the implementation. He knows what he is doing here when it comes to the DMA API, since he made all the patches so far to use it.
Please consider just reviewing the exported function signature:
+struct sg_table *dma_buf_map(struct dma_buf_attachment *attach, + struct p2pdma_provider *provider, + struct dma_buf_phys_vec *phys_vec, + size_t nr_ranges, size_t size, + enum dma_data_direction dir)
If issues are discovered inside the implementation later on then Leon will be available to fix them.
The code is intended to implement that basic function signature which can be thought of as dma_map_resource() done correctly for PCI devices.
So if we could keep those inside the VFIO driver for now I think that should be good to go.
That was several versions ago. Christoph is very strongly against this, he wants to see the new DMA API used by wrapper functions in subsytems related to how the subsystem's data structures work rather than proliferate into drivers. I agree with this, so we need to go in this direction.
Other options, like put the code in the DMA API area, are also not going to be agreed because we really don't want this weird DMABUF use of no-struct page scatterlist to leak out beyond DMABUF.
So, this is the start of a DMA mapping helper API for DMABUF related data structures, it introduces a simplified mapping entry point for drivers that only use MMIO.
As I said I expect this API surface to progress as other DRM drivers are updated (hopefully DRM community will take on this), but there is nothing wrong with starting by having a basic entry point for a narrow use case.
Thanks, Jason