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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Apr 22, 2026 at 01:27:40PM -0600, Alex Williamson wrote:
> I don't know how to qualify the statement in the last paragraph about
> "[t]he only requirement is that the device limit the TPH to only the
> function that is perceiving them", though.  Is that implicit in being
> associated to the dma-buf for the user owned device, or is it a
> property of the suggested steering tags, that we're not validating?

It is a property of VFs and VFIO.

For instance if an insane device allows a steering tag to reach
outside the VF's memory space then it can't really be used with VFIO.

> Steering tags can induce caching abuse, as interpreted in the
> interconnect fabric, but maybe we've already conceded that as
> fundamental aspect of TPH in general.

steering tags are opaque, we don't know what a device will do when it
receives them.

The common CPU issue is indeed cache abuse, but who knows what a
device will do with them.

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

Jason