From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>, Alistair Popple <apopple@nvidia.com>
Cc: Christian Koenig <christian.koenig@amd.com>,
Dongwon Kim <dongwon.kim@intel.com>,
dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
iommu@lists.linux.dev, Kevin Tian <kevin.tian@intel.com>,
Leon Romanovsky <leonro@nvidia.com>,
linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org,
Matthew Brost <matthew.brost@intel.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
Sumit Semwal <sumit.semwal@linaro.org>,
Vivek Kasireddy <vivek.kasireddy@intel.com>
Subject: Re: [PATCH RFC 01/26] dma-buf: Introduce DMA-buf mapping types
Date: Wed, 21 Oct 2026 08:24:40 +0200 [thread overview]
Message-ID: <b5d1bc79fae01fd9b511e06ed796130314ff841b.camel@linux.intel.com> (raw)
In-Reply-To: <1-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvidia.com>
On Tue, 2026-02-17 at 20:11 -0400, Jason Gunthorpe wrote:
> DMA-buf mapping types allow the importer and exporter to negotiate
> the
> format of the map/unmap to be used during the attachment.
>
> Currently DMA-buf only supports struct scatterlist as the attachment
> map
> operation. This is not sufficient for all use cases as dma_addr_t is
> a
> very specific and limited type.
>
> With mapping types the importing driver can declare what it supports.
> For
> example:
>
> struct dma_buf_mapping_match imp_match[] = {
> DMA_BUF_IMAPPING_MY_DRIVER(dev, ...),
> DMA_BUF_IMAPPING_SGT(dev, false),
> };
> attach = dma_buf_mapping_attach(dmabuf, imp_match, ...)
>
> And the exporting driver can declare what it supports:
>
> int exporter_match_mapping(struct dma_buf_match_args *args)
> {
> struct dma_buf_mapping_match exp_match[] = {
> DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...),
> DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false),
> DMA_BUF_EMAPPING_PAL(PAL_ops),
> };
> return dma_buf_match_mapping(args, exp_match, ...);
> }
>
> During dma_buf_mapping_attach() the core code will select a mutual
> match
> between the importer and exporter and record it in the attach-
> >map_type.
>
> Add the basic types:
>
> struct dma_buf_mapping_type
> Type tag and ops for each mapping type.
>
> struct dma_buf_mapping_match
> Entry in a list of importer or exporter match specifications.
> The match specification can be extended by the mapping type with
> unique data.
>
> dma_buf_match_mapping() / struct dma_buf_match_args
> Helper to do the matching. Called by the exporting driver
> via a dma_buf_ops callback.
>
> struct dma_buf_mapping_exp_ops
> Base type for the per-mapping type exporter provided functions.
> This
> would be the map/unmap callbacks. Each mapping type can provide
> its own
> functions for map/unmap type operations with optimal type
> signatures.
Does it make sense to try to land this patch first, plus a conversion
of pcie_p2p so we could agree on what the contract should look like?
s/mapping/interconnect/? My gut feeling is that "interconnect" best
describes what's typically going on, but "mapping" perhaps better
describes all cases.
Location of common protocols which typically carry cross-subsystem
dependencies?
drivers/dma-buf/mapping_types? drivers/dma-buf/interconnects?
As discussed previously:
Agree on theoretically possible matches at attach time, Match at
mapping time and guarantee the match is valid until
invalidate_mappings().
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/dma-buf/dma-buf-mapping.c | 46 +++++++++++++++++++
> include/linux/dma-buf-mapping.h | 76
> +++++++++++++++++++++++++++++++
> include/linux/dma-buf.h | 18 ++++++++
> 3 files changed, 140 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-
> buf-mapping.c
> index b7352e609fbdfa..459c204cabb803 100644
> --- a/drivers/dma-buf/dma-buf-mapping.c
> +++ b/drivers/dma-buf/dma-buf-mapping.c
> @@ -5,6 +5,7 @@
> */
> #include <linux/dma-buf-mapping.h>
> #include <linux/dma-resv.h>
> +#include <linux/dma-buf.h>
>
> static struct scatterlist *fill_sg_entry(struct scatterlist *sgl,
> size_t length,
> dma_addr_t addr)
> @@ -246,3 +247,48 @@ void dma_buf_free_sgt(struct dma_buf_attachment
> *attach, struct sg_table *sgt,
>
> }
> EXPORT_SYMBOL_NS_GPL(dma_buf_free_sgt, "DMA_BUF");
> +
> +/**
> + * dma_buf_match_mapping - Select a mapping type agreed upon by
> exporter and
> + * importer
> + * @args: Match arguments from attach. On success this is updated
> with the
> + * matched exporter and importer entries.
> + * @exp: Array of mapping types supported by the exporter, in
> priority order
> + * @exp_len: Number of entries in @exp
> + *
> + * Iterate over the exporter's supported mapping types and for each
> one search
> + * the importer's list for a compatible matching type. args and
> args->attach are
> + * populated with the resulting match.
> + *
> + * Because the exporter list is walked in order, the exporter
> controls the
> + * priority of mapping types.
> + */
> +int dma_buf_match_mapping(struct dma_buf_match_args *args,
> + const struct dma_buf_mapping_match *exp,
> + size_t exp_len)
> +{
> + const struct dma_buf_mapping_match *exp_end = exp + exp_len;
> + const struct dma_buf_mapping_match *imp_end =
> + args->imp_matches + args->imp_len;
> + int ret;
> +
> + for (; exp != exp_end; exp++) {
> + const struct dma_buf_mapping_match *imp = args-
> >imp_matches;
> +
> + for (; imp != imp_end; imp++) {
> + if (exp->type != imp->type)
> + continue;
> + if (exp->type->match) {
> + ret = exp->type->match(args->dmabuf,
> exp, imp);
> + if (ret == -EOPNOTSUPP)
> + continue;
> + if (ret != 0)
> + return ret;
> + }
> + exp->type->finish_match(args, exp, imp);
> + return 0;
> + }
> + }
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_NS_GPL(dma_buf_match_mapping, "DMA_BUF");
> diff --git a/include/linux/dma-buf-mapping.h b/include/linux/dma-buf-
> mapping.h
> index a3c0ce2d3a42fe..080ccbf3a3f8b8 100644
> --- a/include/linux/dma-buf-mapping.h
> +++ b/include/linux/dma-buf-mapping.h
> @@ -7,6 +7,77 @@
> #define __DMA_BUF_MAPPING_H__
> #include <linux/dma-buf.h>
>
> +struct device;
> +struct dma_buf;
> +struct dma_buf_attachment;
> +struct dma_buf_mapping_exp_ops;
> +
> +/* Type tag for all mapping operations */
> +struct dma_buf_mapping_exp_ops {};
> +
> +/*
> + * Internal struct to pass arguments from the attach function to the
> matching
> + * function
> + */
> +struct dma_buf_match_args {
> + struct dma_buf *dmabuf;
> + struct dma_buf_attachment *attach;
> + const struct dma_buf_mapping_match *imp_matches;
> + size_t imp_len;
> +};
> +
> +/**
> + * struct dma_buf_mapping_type - Operations for a DMA-buf mapping
> type
> + *
> + * Each mapping type provides a singleton instance of this struct to
> describe
> + * the mapping type and its operations.
> + */
> +struct dma_buf_mapping_type {
> + /**
> + * @name: Human-readable name for this mapping type, used in
> debugfs
> + * output
> + */
> + const char *name;
> +
> + /**
> + * @match:
> + *
> + * Called during attach from dma_buf_match_mapping(). &exp
> and &imp are
> + * single items from the importer and exporter mapping match
> lists.
> + * Both will have the same instance of this struct as their
> type member.
> + *
> + * It determines if the exporter/importer are compatible.
> + *
> + * Returns: 0 on success
> + * -EOPNOTSUPP means ignore the failure and continue
> + * Everything else aborts the search and returns the -
> errno
> + */
> + int (*match)(struct dma_buf *dmabuf,
> + const struct dma_buf_mapping_match *exp,
> + const struct dma_buf_mapping_match *imp);
> +
> + /**
> + * @finish_match:
> + *
> + * Called by dma_buf_match_mapping() after a successful
> match to store
> + * the negotiated result in @args->attach. The matched @exp
> and @imp
> + * entries are provided so the callback can copy type-
> specific data into
> + * the attachment.
> + */
> + void (*finish_match)(struct dma_buf_match_args *args,
> + const struct dma_buf_mapping_match
> *exp,
> + const struct dma_buf_mapping_match
> *imp);
> +
> + /**
> + * @debugfs_dump:
> + *
> + * Optional callback to write mapping-type-specific
> diagnostic
> + * information about @attach to the debugfs seq_file @s.
> + */
> + void (*debugfs_dump)(struct seq_file *s,
> + struct dma_buf_attachment *attach);
> +};
> +
> struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment
> *attach,
> struct p2pdma_provider
> *provider,
> struct dma_buf_phys_vec
> *phys_vec,
> @@ -14,4 +85,9 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct
> dma_buf_attachment *attach,
> enum dma_data_direction
> dir);
> void dma_buf_free_sgt(struct dma_buf_attachment *attach, struct
> sg_table *sgt,
> enum dma_data_direction dir);
> +
> +int dma_buf_match_mapping(struct dma_buf_match_args *args,
> + const struct dma_buf_mapping_match
> *exp_mappings,
> + size_t exp_len);
> +
> #endif
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 0bc492090237ed..a2b01b13026810 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -27,6 +27,21 @@
> struct device;
> struct dma_buf;
> struct dma_buf_attachment;
> +struct dma_buf_mapping_type;
> +struct dma_buf_mapping_exp_ops;
> +
> +/*
> + * Match items are generated by the importer using the
> DMA_BUF_IMAPPING_*() and
> + * the exporter using the DMA_BUF_EMAPPING_*() functions. Each
> mapping type
> + * defines its own signature with its own data to make the match and
> attachment.
> + */
> +struct dma_buf_mapping_match {
> + const struct dma_buf_mapping_type *type;
> + const struct dma_buf_mapping_exp_ops *exp_ops;
> + union {
> + /* Each mapping_type has unique match parameters
> here */
> + };
Do we really need to add all global mapping types here? Then we'd need
something for driver-private mapping types as well.
What about just defining a
struct dma_buf_mapping_priv {
};
And let the mapping type subclass from it, and add a pointer to such a
structure?
Thanks,
Thomas
next prev parent reply other threads:[~2026-10-21 6:24 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 0:11 [PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 01/26] dma-buf: Introduce DMA-buf mapping types Jason Gunthorpe
2026-10-21 6:24 ` Thomas Hellström [this message]
2026-10-21 12:37 ` Jason Gunthorpe
2026-10-22 6:52 ` Alistair Popple
2026-10-22 7:25 ` Thomas Hellström
2026-10-22 11:17 ` Alistair Popple
2026-10-22 13:57 ` Thomas Hellström
2026-10-22 11:52 ` Jason Gunthorpe
2026-10-22 12:05 ` Thomas Hellström
2026-10-22 12:11 ` Jason Gunthorpe
2026-10-22 13:30 ` Christian König
2026-10-22 14:00 ` Jason Gunthorpe
2026-10-22 6:59 ` Thomas Hellström
2026-10-22 7:20 ` Alistair Popple
2026-10-22 7:29 ` Thomas Hellström
2026-02-18 0:11 ` [PATCH RFC 02/26] dma-buf: Add the SGT DMA mapping type Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 03/26] dma-buf: Add dma_buf_mapping_attach() Jason Gunthorpe
2026-10-16 20:26 ` Karl Mehltretter
2026-10-19 8:35 ` Christian König
2026-10-19 12:43 ` Thomas Hellström
2026-10-19 13:30 ` Jason Gunthorpe
2026-10-19 13:47 ` Thomas Hellström
2026-10-19 15:34 ` Christian König
2026-10-19 18:41 ` Jason Gunthorpe
2026-10-20 7:01 ` Christian König
2026-10-20 14:31 ` Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 04/26] dma-buf: Route SGT related actions through attach->map_type Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 05/26] dma-buf: Allow single exporter drivers to avoid the match_mapping function Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 06/26] drm: Check the SGT ops for drm_gem_map_dma_buf() Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 07/26] dma-buf: Convert all the simple exporters to use SGT mapping type Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 08/26] drm/vmwgfx: Use match_mapping instead of dummy calls Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 09/26] accel/habanalabs: Use the SGT mapping type Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 10/26] drm/xe/dma-buf: " Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 11/26] drm/amdgpu: " Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 12/26] vfio/pci: Change the DMA-buf exporter to use mapping_type Jason Gunthorpe
2026-04-13 8:29 ` Baolu Lu
2026-04-13 13:01 ` Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 13/26] dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 14/26] iio: buffer: convert " Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 15/26] functionfs: " Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 16/26] dma-buf: Remove unused SGT stuff from the common structures Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 17/26] treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 18/26] treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 19/26] treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 20/26] treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 21/26] dma-buf: Add the Physical Address List DMA mapping type Jason Gunthorpe
2026-04-13 8:58 ` Christian König
2026-04-13 12:16 ` Jason Gunthorpe
2026-04-22 8:17 ` Christian König
2026-04-22 11:53 ` Jason Gunthorpe
2026-04-22 12:39 ` Christian König
2026-04-22 13:13 ` Jason Gunthorpe
2026-04-22 14:04 ` Christian König
2026-04-22 15:00 ` Jason Gunthorpe
2026-05-09 5:31 ` Xu Yilun
2026-05-11 22:48 ` Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 22/26] vfio/pci: Add physical address list support to DMABUF Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 23/26] iommufd: Use the PAL mapping type instead of a vfio function Jason Gunthorpe
2026-10-16 19:40 ` Karl Mehltretter
2026-02-18 0:11 ` [PATCH RFC 24/26] iommufd: Support DMA-bufs with multiple physical ranges Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 25/26] iommufd/selftest: Check multi-phys DMA-buf scenarios Jason Gunthorpe
2026-02-18 0:11 ` [PATCH RFC 26/26] dma-buf: Add kunit tests for mapping type Jason Gunthorpe
2026-03-01 19:05 ` [PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them Jason Gunthorpe
2026-03-03 7:07 ` Kasireddy, Vivek
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=b5d1bc79fae01fd9b511e06ed796130314ff841b.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=apopple@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=leonro@nvidia.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=simona.vetter@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.