Re: [PATCH v1 1/2] vfio: add callback to get tph info for dma-buf

[Alex Williamson <alex@shazbot.org>]

On Thu, 23 Apr 2026 11:28:28 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Wed, Apr 22, 2026 at 01:27:40PM -0600, Alex Williamson wrote:
> 
> > So why does vfio need to be involved in any of the sequence proposed
> > here?  It seems like it would be a much cleaner design, avoiding
> > overloading the existing vfio feature and questionable array semantics,
> > if there were a set-tph ioctl on the resulting dma-buf instead of
> > making some vfio specific interface bundling creation with tph
> > hints.  
> 
> Realistically only VFIO dmabufs will have this property that user
> space can set any TPH.
> 
> Other in-kernel drivers should accept some kind of hint from userspace
> when creating their dmabuf that makes sense for their device, not a
> raw TPH value. Like a GPU might accept a hint that specifies which
> dielet or something like that.
> 
> So I don't see a generality here from that perspective. The generality
> is that exporting drivers that can use TPH now have the option to tell
> the importing driver to send them.

Ok, if dma_buf_ops.get_tph serves the common case of the driver
presenting TPH values and vfio's case of the driver being only a
conduit of user specified TPH values is unique, let's work on the vfio
uAPI.

Why do we need to bundle dma-buf creation and TPH setting into a single
ioctl?  That's what the proposal here does and it results in a really
ugly extension with an off-by-one baked into it.

My suggestion would be that we leave VFIO_DEVICE_FEATURE_DMA_BUF
unchanged and add a VFIO_DEVICE_FEATURE_DMA_BUF_TPH ioctl which takes
the fd from VFIO_DEVICE_FEATURE_DMA_BUF, along with a steering tag and
processing hint.  It would fdget() the dmabuf fd, validate it's a
dmabuf via f_ops, validate it's a vfio exported dmabuf via dmabuf->ops,
find the matching vfio_pci_dma_buf via priv under memory_lock, and
stuff the provided TPH values into the object.  It would be left to the
user to sequence setting the TPH values on the dmabuf before the dmabuf
is consumed by the importer.

Is that a more reasonable uAPI?  Thanks,

Alex