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 <[email protected]> wrote: >> >>> On 11/10/25 21:42, Alex Williamson wrote: >>>> On Thu, 6 Nov 2025 16:16:45 +0200 >>>> Leon Romanovsky <[email protected]> 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
