Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>,
	dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Cc: "Jason Gunthorpe" <jgg@nvidia.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Simona Vetter" <simona.vetter@ffwll.ch>
Subject: Re: [RFC 1/8] dma-buf: Add support for map/unmap APIs for interconnects
Date: Tue, 28 Oct 2025 14:58:57 +0100	[thread overview]
Message-ID: <61c5edcb-2b22-4583-9138-c117bea7a9b3@amd.com> (raw)
In-Reply-To: <20251014071243.811884-2-vivek.kasireddy@intel.com>

On 10/14/25 09:08, Vivek Kasireddy wrote:
> For the map operation, the dma-buf core will create an xarray but
> the exporter is expected to populate it with the interconnect
> specific addresses. And, similarly for unmap, the exporter is
> expected to cleanup the individual entries of the xarray.
> 
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Simona Vetter <simona.vetter@ffwll.ch>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>  drivers/dma-buf/dma-buf.c            | 68 ++++++++++++++++++++++++++++
>  include/linux/dma-buf-interconnect.h | 29 ++++++++++++
>  include/linux/dma-buf.h              | 11 +++++
>  3 files changed, 108 insertions(+)
>  create mode 100644 include/linux/dma-buf-interconnect.h
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 2bcf9ceca997..162642bd53e8 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1612,6 +1612,74 @@ void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
>  }
>  EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, "DMA_BUF");
>  
> +struct dma_buf_ranges *
> +dma_buf_map_interconnect(struct dma_buf_attachment *attach)
> +{
> +	const struct dma_buf_interconnect_ops *ic_ops;
> +	struct dma_buf *dmabuf = attach->dmabuf;
> +	struct dma_buf_ranges *ranges;
> +	int ret;
> +
> +	might_sleep();
> +
> +	if (WARN_ON(!attach || !attach->dmabuf))
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!dma_buf_attachment_is_dynamic(attach))
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!attach->allow_ic)
> +		return ERR_PTR(-EOPNOTSUPP);
> +
> +	dma_resv_assert_held(attach->dmabuf->resv);
> +
> +	ic_ops = dmabuf->ops->interconnect_ops;
> +	if (!ic_ops || !ic_ops->map_interconnect)
> +		return ERR_PTR(-EINVAL);
> +
> +	ranges = kzalloc(sizeof(*ranges), GFP_KERNEL);
> +	if (!ranges)
> +		return ERR_PTR(-ENOMEM);
> +
> +	xa_init(&ranges->ranges);
> +	ret = ic_ops->map_interconnect(attach, ranges);
> +	if (ret)
> +		goto err_free_ranges;
> +
> +	return ranges;
> +
> +err_free_ranges:
> +	xa_destroy(&ranges->ranges);
> +	kfree(ranges);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_NS_GPL(dma_buf_map_interconnect, "DMA_BUF");
> +
> +void dma_buf_unmap_interconnect(struct dma_buf_attachment *attach,
> +				struct dma_buf_ranges *ranges)
> +{
> +	const struct dma_buf_interconnect_ops *ic_ops;
> +	struct dma_buf *dmabuf = attach->dmabuf;
> +
> +	if (WARN_ON(!attach || !attach->dmabuf || !ranges))
> +		return;
> +
> +	if (!attach->allow_ic)
> +		return;
> +
> +	ic_ops = dmabuf->ops->interconnect_ops;
> +	if (!ic_ops || !ic_ops->unmap_interconnect)
> +		return;
> +
> +	dma_resv_assert_held(attach->dmabuf->resv);
> +
> +	ic_ops->unmap_interconnect(attach, ranges);
> +
> +	xa_destroy(&ranges->ranges);
> +	kfree(ranges);
> +}
> +EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_interconnect, "DMA_BUF");
> +
>  #ifdef CONFIG_DEBUG_FS
>  static int dma_buf_debug_show(struct seq_file *s, void *unused)
>  {
> diff --git a/include/linux/dma-buf-interconnect.h b/include/linux/dma-buf-interconnect.h
> new file mode 100644
> index 000000000000..17504dea9691
> --- /dev/null
> +++ b/include/linux/dma-buf-interconnect.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +#ifndef __DMA_BUF_INTERCONNECT_H__
> +#define __DMA_BUF_INTERCONNECT_H__
> +
> +#include <linux/xarray.h>
> +
> +struct dma_buf_attachment;
> +
> +struct dma_buf_ranges {
> +	struct xarray ranges;
> +	unsigned int nranges;
> +};

Hui? How is that supposed to work? Should the exporter fill in the xarray with values?

That clearly needs more description.

And IIRC xarray can only contain pointers because the lower bits are used for internal handling.

Some kind of iterator like interface would be preferred where you have first and next callbacks.

> +
> +enum dma_buf_interconnect_type {
> +	DMA_BUF_INTERCONNECT_NONE = 0,

Let's start with a DMA_BUF_DMA_ADDR type.

> +};
> +
> +struct dma_buf_interconnect {
> +	enum dma_buf_interconnect_type type;
> +};
> +
> +struct dma_buf_interconnect_ops {
> +	int (*map_interconnect)(struct dma_buf_attachment *attach,
> +				struct dma_buf_ranges *ranges);
> +	void (*unmap_interconnect)(struct dma_buf_attachment *attach,
> +				   struct dma_buf_ranges *ranges);
> +};

Please put those directly into the dma_buf_ops structure, I don't really see a value in separating them.

Additional to that I'm not sure if the "interconnect" is a good naming, essentially we want to use the new mapping functions to replace the sg_table as well.

Regards,
Christian.

> +#endif
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d58e329ac0e7..db91c67c00d6 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -23,6 +23,8 @@
>  #include <linux/dma-fence.h>
>  #include <linux/wait.h>
>  
> +#include <linux/dma-buf-interconnect.h>
> +
>  struct device;
>  struct dma_buf;
>  struct dma_buf_attachment;
> @@ -276,6 +278,8 @@ struct dma_buf_ops {
>  
>  	int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map);
>  	void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map *map);
> +
> +	const struct dma_buf_interconnect_ops *interconnect_ops;
>  };
>  
>  /**
> @@ -502,7 +506,9 @@ struct dma_buf_attachment {
>  	struct device *dev;
>  	struct list_head node;
>  	bool peer2peer;
> +	bool allow_ic;
>  	const struct dma_buf_attach_ops *importer_ops;
> +	struct dma_buf_interconnect interconnect;
>  	void *importer_priv;
>  	void *priv;
>  };
> @@ -589,6 +595,11 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
>  					enum dma_data_direction);
>  void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>  				enum dma_data_direction);
> +
> +struct dma_buf_ranges *dma_buf_map_interconnect(struct dma_buf_attachment *);
> +void dma_buf_unmap_interconnect(struct dma_buf_attachment *,
> +				struct dma_buf_ranges *);
> +
>  void dma_buf_move_notify(struct dma_buf *dma_buf);
>  int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>  			     enum dma_data_direction dir);


  parent reply	other threads:[~2025-10-28 13:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  7:08 [RFC 0/8] dma-buf: Add support for mapping dmabufs via interconnects Vivek Kasireddy
2025-10-14  7:08 ` [RFC 1/8] dma-buf: Add support for map/unmap APIs for interconnects Vivek Kasireddy
2025-10-20  9:34   ` Thomas Hellström
2025-10-21  5:45     ` Kasireddy, Vivek
2025-10-28 13:58   ` Christian König [this message]
2025-10-28 14:05     ` Jason Gunthorpe
2025-10-28 14:14       ` Christian König
2025-10-28 14:44         ` Jason Gunthorpe
2025-10-14  7:08 ` [RFC 2/8] dma-buf: Add a helper to match interconnects between exporter/importer Vivek Kasireddy
2025-10-17 15:58   ` Kasireddy, Vivek
2025-10-14  7:08 ` [RFC 3/8] dma-buf: Add support for IOV interconnect Vivek Kasireddy
2025-10-14  7:08 ` [RFC 4/8] vfio/pci/dmabuf: " Vivek Kasireddy
2025-10-14  7:08 ` [RFC 5/8] drm/xe/dma_buf: " Vivek Kasireddy
2025-10-14  7:08 ` [RFC 6/8] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM Vivek Kasireddy
2025-10-14  7:08 ` [RFC 7/8] drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs Vivek Kasireddy
2025-10-14  7:08 ` [RFC 8/8] drm/xe/pt: Add an additional check for dmabuf BOs while doing bind Vivek Kasireddy

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=61c5edcb-2b22-4583-9138-c117bea7a9b3@amd.com \
    --to=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=simona.vetter@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=vivek.kasireddy@intel.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