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. Regards, Christian. > That's why the ST has to flow through a uAPI: userspace owns the > device and its ST table, so it's the only entity that can publish a > meaningful value for a given dma-buf. > > On the effect: the endpoint's PCIe ingress block uses the 8-bit ST as > an in-band instruction for the incoming P2P TLP — selecting a target > cache partition and, on writes, an in-flight operation on the data > before it lands. The dma-buf callback keeps this opaque to the > framework — only the producer (userspace owner of the VFIO device) and > the consumer (endpoint block) need to interpret the value. > > will include these words into v6's cover letter. > > Thanks, > Zhiping
