On Tue, May 5, 2026 at 11:58 PM fengchengwen <[email protected]> wrote:
>
> >
> On 5/1/2026 4:06 AM, Zhiping Zhang wrote:
> > Add a dma-buf callback that returns raw TPH metadata from the exporter
> > so peer devices can reuse the steering tag and processing hint
> > associated with a VFIO-exported buffer.
> >
> > Add a new VFIO_DEVICE_FEATURE_DMA_BUF_TPH ioctl that takes the fd from
> > VFIO_DEVICE_FEATURE_DMA_BUF along with a steering tag and processing
> > hint, validates the fd is a vfio-exported dma-buf belonging to this
> > device, and stores the TPH values under memory_lock. This keeps the
> > existing VFIO_DEVICE_FEATURE_DMA_BUF uAPI completely unchanged.
> >
> > The user sequences setting TPH on the dma-buf before the importer
> > consumes it.
> >
> > Add an st_width parameter to get_tph() so the exporter can reject
> > steering tags that exceed the consumer's supported width (8 vs 16 bit).
> > When no TPH metadata was supplied, get_tph() returns -EOPNOTSUPP.
> >
> > Signed-off-by: Zhiping Zhang <[email protected]>
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > b/drivers/vfio/pci/vfio_pci_core.c
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -1534,6 +1534,9 @@ int vfio_pci_core_ioctl_feature(struct vfio_device
> > *device, u32 flags,
> > return vfio_pci_core_feature_token(vdev, flags, arg, argsz);
> > case VFIO_DEVICE_FEATURE_DMA_BUF:
> > return vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);
> > + case VFIO_DEVICE_FEATURE_DMA_BUF_TPH:
> > + return vfio_pci_core_feature_dma_buf_tph(vdev, flags, arg,
> > + argsz);
> > default:
> > return -ENOTTY;
> > }
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -19,6 +19,9 @@ struct vfio_pci_dma_buf {
> > u32 nr_ranges;
> > struct kref kref;
> > struct completion comp;
> > + u16 steering_tag;
> > + u8 ph;
> > + u8 tph_present : 1;
> > u8 revoked : 1;
> > };
> >
> > @@ -69,6 +72,22 @@ vfio_pci_dma_buf_map(struct dma_buf_attachment
> > *attachment,
> > return ret;
> > }
> >
> > +static int vfio_pci_dma_buf_get_tph(struct dma_buf *dmabuf, u16
> > *steering_tag,
> > + u8 *ph, u8 st_width)
> > +{
> > + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> > +
> > + if (!priv->tph_present)
> > + return -EOPNOTSUPP;
> > +
> > + if (st_width < 16 && priv->steering_tag > ((1U << st_width) - 1))
> > + return -EINVAL;
>
> The checker will failed in following cases:
> 1. If the exporter passed 8bit st, and importer support 16bit st, then it
> will pass
> the checker.
> 2. The exporter enabled 16bit st and its st is < 256 (note: the pcie protocol
> doesn't
> restrict 16bit-st must >=256), and importer only support 8bit st, then it
> will also
> pass the checker
>
> Suggest userspace passing both st(8bit) and extend-st(16bit), and importer
> chose the
> right one.
>
Agreed — 8-bit ST and 16-bit Extended ST are distinct namespaces
(firmware returns
them as separate fields with separate validity bits), so a numeric
range check is insufficient.
For v3 I'll change the uAPI to carry both, gated by a flags field:
#define VFIO_DMA_BUF_TPH_ST (1 << 0) /* steering_tag valid */
#define VFIO_DMA_BUF_TPH_ST_EXT (1 << 1) /* steering_tag_ext valid
*/
struct vfio_device_feature_dma_buf_tph {
__s32 dmabuf_fd;
__u32 flags;
__u16 steering_tag; /* 8-bit ST */
__u16 steering_tag_ext; /* 16-bit Extended ST */
__u8 ph;
__u8 reserved[3];
};
get_tph() then picks the field matching the importer's st_width and
returns -EOPNOTSUPP
if that one isn't valid.
Thanks,
Zhiping
