On Mon, Nov 17, 2025 at 08:36:20AM -0700, Alex Williamson wrote:
On Tue, 11 Nov 2025 09:54:22 +0100 Christian König christian.koenig@amd.com wrote:
On 11/10/25 21:42, Alex Williamson wrote:
On Thu, 6 Nov 2025 16:16:45 +0200 Leon Romanovsky leon@kernel.org wrote:
Changelog: v7:
- Dropped restore_revoke flag and added vfio_pci_dma_buf_move to reverse loop.
- Fixed spelling errors in documentation patch.
- Rebased on top of v6.18-rc3.
- Added include to stddef.h to vfio.h, to keep uapi header file independent.
I think we're winding down on review comments. It'd be great to get p2pdma and dma-buf acks on this series. Otherwise it's been posted enough that we'll assume no objections. Thanks,
Already have it on my TODO list to take a closer look, but no idea when that will be.
This patch set is on place 4 or 5 on a rather long list of stuff to review/finish.
Hi Christian,
Gentle nudge. Leon posted v8[1] last week, which is not drawing any new comments. Do you foresee having time for review that I should still hold off merging for v6.19 a bit longer? Thanks,
I really want this merged this cycle, along with the iommufd part, which means it needs to go into your tree by very early next week on a shared branch so I can do the iommufd part on top.
It is the last blocking kernel piece to conclude the viommu support roll out into qemu for iommufd which quite a lot of people have been working on for years now.
IMHO there is nothing profound in the dmabuf patch, it was written by the expert in the new DMA API operation, and doesn't form any troublesome API contracts. It is also the same basic code as from the v1 in July just moved into dmabuf .c files instead of vfio .c files at Christoph's request.
My hope is DRM folks will pick up the baton and continue to improve this to move other drivers away from dma_map_resource(). Simona told me people have wanted DMA API improvements for ages, now we have them, now is the time!
Any remarks after the fact can be addressed incrementally.
If there are no concrete technical remarks please take it. 6 months is long enough to wait for feedback.
Thanks, Jason
On 11/17/25 18:16, Jason Gunthorpe wrote:
On Mon, Nov 17, 2025 at 08:36:20AM -0700, Alex Williamson wrote:
On Tue, 11 Nov 2025 09:54:22 +0100 Christian König christian.koenig@amd.com wrote:
On 11/10/25 21:42, Alex Williamson wrote:
On Thu, 6 Nov 2025 16:16:45 +0200 Leon Romanovsky leon@kernel.org wrote:
Changelog: v7:
- Dropped restore_revoke flag and added vfio_pci_dma_buf_move to reverse loop.
- Fixed spelling errors in documentation patch.
- Rebased on top of v6.18-rc3.
- Added include to stddef.h to vfio.h, to keep uapi header file independent.
I think we're winding down on review comments. It'd be great to get p2pdma and dma-buf acks on this series. Otherwise it's been posted enough that we'll assume no objections. Thanks,
Already have it on my TODO list to take a closer look, but no idea when that will be.
This patch set is on place 4 or 5 on a rather long list of stuff to review/finish.
Hi Christian,
Gentle nudge. Leon posted v8[1] last week, which is not drawing any new comments. Do you foresee having time for review that I should still hold off merging for v6.19 a bit longer? Thanks,
I really want this merged this cycle, along with the iommufd part, which means it needs to go into your tree by very early next week on a shared branch so I can do the iommufd part on top.
It is the last blocking kernel piece to conclude the viommu support roll out into qemu for iommufd which quite a lot of people have been working on for years now.
IMHO there is nothing profound in the dmabuf patch, it was written by the expert in the new DMA API operation, and doesn't form any troublesome API contracts. It is also the same basic code as from the v1 in July just moved into dmabuf .c files instead of vfio .c files at Christoph's request.
As long as it is only an internal API between iommu and vfio which also respects the standard DMA-buf semantics to either pin buffers or provide a move_notify interface then feel free to go ahead with it.
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.
So if we could keep those inside the VFIO driver for now I think that should be good to go.
Regards, Christian.
My hope is DRM folks will pick up the baton and continue to improve this to move other drivers away from dma_map_resource(). Simona told me people have wanted DMA API improvements for ages, now we have them, now is the time!
Any remarks after the fact can be addressed incrementally.
If there are no concrete technical remarks please take it. 6 months is long enough to wait for feedback.
Thanks, Jason
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
linaro-mm-sig@lists.linaro.org
-
Christian König -
Jason Gunthorpe