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.
> 
> 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.
> 
> > - the device is a Meta MTIA
> > accelerator managed entirely from userspace via VFIO passthrough.
> 
> 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.
> 
> But as far as I can see without upstreaming or at least open sourcing the 
> full stack to utilize this functionality it's a clear NAK to upstreaming this.

But the existing dmabuf for vfio-pci was accepted upstream without these
requirements. I see you had concerns about even that, but still Acked
under the same model that's propsed in this series:

  
https://lore.kernel.org/linux-pci/[email protected]/

So with vfio-pci and mlx5 both in-tree dmabuf users, implementing and
consuming the callback, does this not satisfy the requirement? The
userspace-driven semantics are inherent to VFIO's design. I don't see
what additional value open sourcing the user-side provides for the
kernel-side review process.

Reply via email to