Re: [PATCH v5 0/4] vfio/dma-buf: add TPH support for peer-to-peer access

["Christian König" <christian.koenig@amd.com>]

On 5/29/26 22:31, Keith Busch 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.
>>
>> 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/57b8876f-1399-4e4d-a44b-1177787aa17d@amd.com/

Well that wasn't driver to driver API but just some helpers which we didn't know where else to but.

This here is an addition to the inter driver API which as far as I can see is currently not beneficial to anybody else.

> 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.

Well upstreaming something into Linus tree only makes sense if others can use it.

And as far as I can see without all components available this is not the case.

Regards,
Christian.