On 5/29/26 22:11, Jason Gunthorpe wrote: > On Fri, May 29, 2026 at 09:36:00AM +0200, Christian König wrote: >> On 5/29/26 08:34, Zhiping Zhang wrote: >> ... >>> There's no in-tree vendor PF driver >> >> Well I have to admit it's a bit on the edge but this sentence is a >> show stopper. > > I think he means the device is not SRIOV. vfio-pci is the in-kernel PF > driver. > >> DMA-buf is an in kernel interface for buffer sharing between drivers >> and any change to it needs an in kernel driver as justification for >> the added complexity. > > vfio is the in-kernel driver, this series fully shows the in-kernel > API using vfio as the exporter and mlx5 as the importer. It certainly > meets the standard required to show in-tree users. > >> When you have a complete open source driver stack which utilizes >> VFIO passthrough as the interface to communicate with the kernel >> drivers then we can eventually talk about that. > > That decision is not up to dmabuf
Yes it is. This is the DMA-buf API which is added here. > - what VFIO subsystem requires to > accept a new UAPI is up to the VFIO maintainers. As far as I can see vfio-pci is used as a stub driver to avoid opening up the real driver. Upstreaming an API changes only makes sense if others can use it and this here is something completely special to this particular use case, without all components involved nobody else can use it. So as far as I can see that here is a no-go. But at the end of the day it's Linus who needs to say if that's ok or not, that's why I put him on CC. Regards, Christian. > DRM and VFIO have very different views on what is required to merge a > new uAPI. > > Jason
