From: "Christian König" <christian.koenig@amd.com>
To: Zhiping Zhang <zhipingz@meta.com>,
Alex Williamson <alex@shazbot.org>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
kvm@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-pci@vger.kernel.org, netdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, Keith Busch <kbusch@kernel.org>,
Yochai Cohen <yochai@nvidia.com>,
Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH v7 3/5] dma-buf: add optional get_tph() callback
Date: Thu, 11 Jun 2026 12:35:48 +0200 [thread overview]
Message-ID: <98b65e1f-1b5f-47fc-a4fb-0cdfab6725ed@amd.com> (raw)
In-Reply-To: <20260610193158.2614209-4-zhipingz@meta.com>
On 6/10/26 21:31, Zhiping Zhang wrote:
> Add an optional dma_buf_ops.get_tph callback and a dma_buf_get_tph()
> wrapper for importers.
>
> 8-bit ST and 16-bit Extended ST are distinct PCIe TPH namespaces, so
> the importer requests the namespace it can emit and the exporter
> returns the matching ST/PH tuple or -EOPNOTSUPP.
>
> dma_buf_get_tph() is the importer entry point. It returns -EOPNOTSUPP
> when the exporter lacks the callback and requires dmabuf->resv to be
> held while the callback runs.
>
> The first user is VFIO_DEVICE_FEATURE_DMA_BUF_TPH in vfio-pci, with
> mlx5 as the first importer.
>
> Signed-off-by: Zhiping Zhang <zhipingz@meta.com>
> ---
> drivers/dma-buf/dma-buf.c | 25 +++++++++++++++++++++++++
> include/linux/dma-buf.h | 21 +++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d504c636dc29..aff79ea12e43 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1144,6 +1144,31 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
> }
> EXPORT_SYMBOL_NS_GPL(dma_buf_unpin, "DMA_BUF");
>
> +/**
> + * dma_buf_get_tph - Retrieve TPH metadata from an exporter
> + * @dmabuf: DMA buffer to query
> + * @extended: false for 8-bit ST, true for 16-bit Extended ST
> + * @steering_tag: returns the raw steering tag for the requested namespace
> + * @ph: returns the TPH processing hint
> + *
> + * Wrapper for the optional &dma_buf_ops.get_tph callback.
> + *
> + * Must be called with &dma_buf.resv held. Returns -EOPNOTSUPP if the
> + * exporter does not implement the callback or has no metadata for the
> + * requested namespace.
> + */
> +int dma_buf_get_tph(struct dma_buf *dmabuf, bool extended,
> + u16 *steering_tag, u8 *ph)
That name needs improvement, maybe something like dma_buf_get_pci_tph().
It also needs some brief explanation what TPH is, maybe a reference to the PCIe spec name etc...
And document in the list of functions that this one should be called with the lock held.
> +{
> + dma_resv_assert_held(dmabuf->resv);
> +
> + if (!dmabuf->ops->get_tph)
> + return -EOPNOTSUPP;
> +
> + return dmabuf->ops->get_tph(dmabuf, extended, steering_tag, ph);
> +}
> +EXPORT_SYMBOL_NS_GPL(dma_buf_get_tph, "DMA_BUF");
> +
> /**
> * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
> * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d1203da56fc5..6a54e0f251a2 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -113,6 +113,25 @@ struct dma_buf_ops {
> */
> void (*unpin)(struct dma_buf_attachment *attach);
>
> + /**
> + * @get_tph:
> + * @dmabuf: DMA buffer for which to retrieve TPH metadata
> + * @extended: false for 8-bit ST, true for 16-bit Extended ST
> + * @steering_tag: Returns the raw TPH steering tag for the requested
> + * namespace
> + * @ph: Returns the TPH processing hint (2-bit value)
> + *
> + * Return TPH metadata for the namespace selected by @extended. Return
> + * 0 on success, or -EOPNOTSUPP if no metadata is available.
> + *
> + * This callback is optional. Importers must not call it directly;
> + * the dma_buf_get_tph() wrapper is the only entry point and handles
> + * the NULL-callback case. The callback is invoked with
> + * &dma_buf.resv held.
That most of that should be obvious, we only need that it's optional and that the lock should be held. Everything else can be dropped.
And most of the description/documentation should be on the wrapper function, exporters who implement the callback should know what they are doing.
Regards,
Christian.
> + */
> + int (*get_tph)(struct dma_buf *dmabuf, bool extended,
> + u16 *steering_tag, u8 *ph);
> +
> /**
> * @map_dma_buf:
> *
> @@ -563,6 +582,8 @@ void dma_buf_detach(struct dma_buf *dmabuf,
> struct dma_buf_attachment *attach);
> int dma_buf_pin(struct dma_buf_attachment *attach);
> void dma_buf_unpin(struct dma_buf_attachment *attach);
> +int dma_buf_get_tph(struct dma_buf *dmabuf, bool extended,
> + u16 *steering_tag, u8 *ph);
>
> struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>
next prev parent reply other threads:[~2026-06-11 10:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260610193158.2614209-1-zhipingz@meta.com>
[not found] ` <20260610193158.2614209-2-zhipingz@meta.com>
2026-06-11 7:47 ` [PATCH v7 1/5] net/mlx5: free mlx5_st_idx_data on final dealloc Christian König
2026-06-11 22:53 ` Zhiping Zhang
2026-06-11 23:45 ` Zhiping Zhang
[not found] ` <20260610193158.2614209-4-zhipingz@meta.com>
2026-06-11 10:35 ` Christian König [this message]
2026-06-11 23:07 ` [PATCH v7 3/5] dma-buf: add optional get_tph() callback Zhiping Zhang
[not found] ` <20260610193158.2614209-6-zhipingz@meta.com>
2026-06-11 12:44 ` [PATCH v7 5/5] RDMA/mlx5: get tph for p2p access when registering dma-buf mr Michael Gur
2026-06-11 23:09 ` Zhiping Zhang
2026-06-11 16:11 [PATCH v7 0/5] vfio/dma-buf: add TPH support for peer-to-peer access Zhiping Zhang
2026-06-11 16:11 ` [PATCH v7 3/5] dma-buf: add optional get_tph() callback Zhiping Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98b65e1f-1b5f-47fc-a4fb-0cdfab6725ed@amd.com \
--to=christian.koenig@amd.com \
--cc=alex@shazbot.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=helgaas@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kbusch@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=yishaih@nvidia.com \
--cc=yochai@nvidia.com \
--cc=zhipingz@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox