linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Christian König" <christian.koenig@amd.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Logan Gunthorpe <logang@deltatee.com>,
	Jens Axboe <axboe@kernel.dk>, Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Kees Cook <kees@kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Ankit Agrawal <ankita@nvidia.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Shameer Kolothum <skolothumtho@nvidia.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Alex Williamson <alex@shazbot.org>,
	Krishnakant Jaju <kjaju@nvidia.com>, Matt Ochs <mochs@nvidia.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-block@vger.kernel.org, iommu@lists.linux.dev,
	linux-mm@kvack.org, linux-doc@vger.kernel.org,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, kvm@vger.kernel.org,
	linux-hardening@vger.kernel.org, Alex Mastro <amastro@fb.com>,
	Nicolin Chen <nicolinc@nvidia.com>
Subject: Re: [Linaro-mm-sig] [PATCH v8 06/11] dma-buf: provide phys_vec to scatter-gather mapping routine
Date: Wed, 19 Nov 2025 09:25:11 -0400	[thread overview]
Message-ID: <20251119132511.GK17968@ziepe.ca> (raw)
In-Reply-To: <8a11b605-6ac7-48ac-8f27-22df7072e4ad@amd.com>

On Wed, Nov 19, 2025 at 02:16:57PM +0100, Christian König wrote:
> > +/**
> > + * dma_buf_map - Returns the scatterlist table of the attachment from arrays
> > + * of physical vectors. This funciton is intended for MMIO memory only.
> > + * @attach:	[in]	attachment whose scatterlist is to be returned
> > + * @provider:	[in]	p2pdma provider
> > + * @phys_vec:	[in]	array of physical vectors
> > + * @nr_ranges:	[in]	number of entries in phys_vec array
> > + * @size:	[in]	total size of phys_vec
> > + * @dir:	[in]	direction of DMA transfer
> > + *
> > + * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
> > + * on error. May return -EINTR if it is interrupted by a signal.
> > + *
> > + * On success, the DMA addresses and lengths in the returned scatterlist are
> > + * PAGE_SIZE aligned.
> > + *
> > + * A mapping must be unmapped by using dma_buf_unmap().
> > + */
> > +struct sg_table *dma_buf_map(struct dma_buf_attachment *attach,
> 
> That is clearly not a good name for this function. We already have overloaded the term *mapping* with something completely different.
> 
> > +			     struct p2pdma_provider *provider,
> > +			     struct dma_buf_phys_vec *phys_vec,
> > +			     size_t nr_ranges, size_t size,
> > +			     enum dma_data_direction dir)
> > +{
> > +	unsigned int nents, mapped_len = 0;
> > +	struct dma_buf_dma *dma;
> > +	struct scatterlist *sgl;
> > +	dma_addr_t addr;
> > +	size_t i;
> > +	int ret;
> > +
> > +	dma_resv_assert_held(attach->dmabuf->resv);
> > +
> > +	if (WARN_ON(!attach || !attach->dmabuf || !provider))
> > +		/* This function is supposed to work on MMIO memory only */
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> > +	if (!dma)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	switch (pci_p2pdma_map_type(provider, attach->dev)) {
> > +	case PCI_P2PDMA_MAP_BUS_ADDR:
> > +		/*
> > +		 * There is no need in IOVA at all for this flow.
> > +		 */
> > +		break;
> > +	case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> > +		dma->state = kzalloc(sizeof(*dma->state), GFP_KERNEL);
> > +		if (!dma->state) {
> > +			ret = -ENOMEM;
> > +			goto err_free_dma;
> > +		}
> > +
> > +		dma_iova_try_alloc(attach->dev, dma->state, 0, size);
> 
> Oh, that is a clear no-go for the core DMA-buf code.
> 
> It's intentionally up to the exporter how to create the DMA
> addresses the importer can work with.

I can't fully understand this remark?

> We could add something like a dma_buf_sg_helper.c or similar and put it in there.

Yes, the intention is this function is an "exporter helper" that an
exporter can call if it wants to help generate the scatterlist.

So your "no-go" is just about what file it is in, not anything about
how it works?

Thanks,
Jason

  reply	other threads:[~2025-11-19 13:25 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11  9:57 [PATCH v8 00/11] vfio/pci: Allow MMIO regions to be exported through dma-buf Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 01/11] PCI/P2PDMA: Separate the mmap() support from the core logic Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 02/11] PCI/P2PDMA: Simplify bus address mapping API Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 03/11] PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 04/11] PCI/P2PDMA: Provide an access to pci_p2pdma_map_type() function Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 05/11] PCI/P2PDMA: Document DMABUF model Leon Romanovsky
2025-11-19  9:18   ` Christian König
2025-11-19 13:13     ` Leon Romanovsky
2025-11-19 13:35     ` Jason Gunthorpe
2025-11-19 14:06       ` Christian König
2025-11-19 19:45         ` Jason Gunthorpe
2025-11-19 20:45           ` Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 06/11] dma-buf: provide phys_vec to scatter-gather mapping routine Leon Romanovsky
2025-11-18 23:02   ` Jason Gunthorpe
2025-11-19  0:06   ` Nicolin Chen
2025-11-19 13:32     ` Leon Romanovsky
2025-11-19  5:54   ` Tian, Kevin
2025-11-19 13:30     ` Leon Romanovsky
2025-11-19 13:37       ` Jason Gunthorpe
2025-11-19 13:45         ` Leon Romanovsky
2025-11-19 13:16   ` [Linaro-mm-sig] " Christian König
2025-11-19 13:25     ` Jason Gunthorpe [this message]
2025-11-19 13:42       ` Christian König
2025-11-19 13:48         ` Leon Romanovsky
2025-11-19 19:31         ` Jason Gunthorpe
2025-11-19 20:54           ` Leon Romanovsky
2025-11-20  7:08           ` Christian König
2025-11-20  7:41             ` Leon Romanovsky
2025-11-20  7:54               ` Christian König
2025-11-20  8:06                 ` Leon Romanovsky
2025-11-20  8:32                   ` Christian König
2025-11-20  8:42                     ` Leon Romanovsky
2025-11-20 13:20             ` Jason Gunthorpe
2025-11-19 13:42     ` Leon Romanovsky
2025-11-19 14:11       ` Christian König
2025-11-19 14:50         ` Leon Romanovsky
2025-11-19 14:53           ` Christian König
2025-11-19 15:41             ` Leon Romanovsky
2025-11-19 16:33             ` Leon Romanovsky
2025-11-20  7:03               ` Christian König
2025-11-20  7:38                 ` Leon Romanovsky
2025-11-19 19:36         ` Jason Gunthorpe
2025-11-11  9:57 ` [PATCH v8 07/11] vfio: Export vfio device get and put registration helpers Leon Romanovsky
2025-11-18  7:10   ` Tian, Kevin
2025-11-11  9:57 ` [PATCH v8 08/11] vfio/pci: Share the core device pointer while invoking feature functions Leon Romanovsky
2025-11-18  7:11   ` Tian, Kevin
2025-11-11  9:57 ` [PATCH v8 09/11] vfio/pci: Enable peer-to-peer DMA transactions by default Leon Romanovsky
2025-11-18  7:18   ` Tian, Kevin
2025-11-18 20:10     ` Alex Williamson
2025-11-19  0:01       ` Tian, Kevin
2025-11-18 20:18     ` Keith Busch
2025-11-19  0:02       ` Tian, Kevin
2025-11-19 13:54         ` Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 10/11] vfio/pci: Add dma-buf export support for MMIO regions Leon Romanovsky
2025-11-18  7:33   ` Tian, Kevin
2025-11-18 14:28     ` Jason Gunthorpe
2025-11-18 23:56       ` Tian, Kevin
2025-11-19 19:41         ` Jason Gunthorpe
2025-11-19 20:50           ` Leon Romanovsky
2025-11-11  9:57 ` [PATCH v8 11/11] vfio/nvgrace: Support get_dmabuf_phys Leon Romanovsky
2025-11-18  7:34   ` Tian, Kevin
2025-11-18  7:59   ` Ankit Agrawal
2025-11-18 14:30     ` Jason Gunthorpe

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=20251119132511.GK17968@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=akpm@linux-foundation.org \
    --cc=alex@shazbot.org \
    --cc=amastro@fb.com \
    --cc=ankita@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavoars@kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kees@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=kjaju@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mochs@nvidia.com \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=skolothumtho@nvidia.com \
    --cc=sumit.semwal@linaro.org \
    --cc=will@kernel.org \
    --cc=yishaih@nvidia.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;
as well as URLs for NNTP newsgroup(s).