From: Luis Chamberlain <mcgrof@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: "Marek Szyprowski" <m.szyprowski@samsung.com>,
"Jens Axboe" <axboe@kernel.dk>, "Christoph Hellwig" <hch@lst.de>,
"Keith Busch" <kbusch@kernel.org>,
"Leon Romanovsky" <leonro@nvidia.com>, "Jake Edge" <jake@lwn.net>,
"Jonathan Corbet" <corbet@lwn.net>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Zhu Yanjun" <zyjzyj2000@gmail.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
"Sagi Grimberg" <sagi@grimberg.me>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Logan Gunthorpe" <logang@deltatee.com>,
"Yishai Hadas" <yishaih@nvidia.com>,
"Shameer Kolothum" <shameerali.kolothum.thodi@huawei.com>,
"Kevin Tian" <kevin.tian@intel.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, linux-rdma@vger.kernel.org,
iommu@lists.linux.dev, linux-nvme@lists.infradead.org,
linux-pci@vger.kernel.org, kvm@vger.kernel.org,
linux-mm@kvack.org, "Niklas Schnelle" <schnelle@linux.ibm.com>,
"Chuck Lever" <chuck.lever@oracle.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Kanchan Joshi" <joshi.k@samsung.com>,
"Chaitanya Kulkarni" <kch@nvidia.com>
Subject: Re: [PATCH v9 07/24] dma-mapping: Implement link/unlink ranges API
Date: Sat, 26 Apr 2025 15:46:30 -0700 [thread overview]
Message-ID: <aA1iRtCsPkuprI-X@bombadil.infradead.org> (raw)
In-Reply-To: <2d6ca43ef8d26177d7674b9e3bdf0fe62b55a7ed.1745394536.git.leon@kernel.org>
On Wed, Apr 23, 2025 at 11:12:58AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Introduce new DMA APIs to perform DMA linkage of buffers
> in layers higher than DMA.
>
> In proposed API, the callers will perform the following steps.
> In map path:
> if (dma_can_use_iova(...))
> dma_iova_alloc()
> for (page in range)
> dma_iova_link_next(...)
> dma_iova_sync(...)
> else
> /* Fallback to legacy map pages */
> for (all pages)
> dma_map_page(...)
>
> In unmap path:
> if (dma_can_use_iova(...))
> dma_iova_destroy()
> else
> for (all pages)
> dma_unmap_page(...)
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Tested-by: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/iommu/dma-iommu.c | 261 ++++++++++++++++++++++++++++++++++++
> include/linux/dma-mapping.h | 32 +++++
> 2 files changed, 293 insertions(+)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index d2c298083e0a..2e014db5a244 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1818,6 +1818,267 @@ void dma_iova_free(struct device *dev, struct dma_iova_state *state)
> }
> EXPORT_SYMBOL_GPL(dma_iova_free);
>
> +static int __dma_iova_link(struct device *dev, dma_addr_t addr,
> + phys_addr_t phys, size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + bool coherent = dev_is_dma_coherent(dev);
> +
> + if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> + arch_sync_dma_for_device(phys, size, dir);
So arch_sync_dma_for_device() is a no-op on some architectures, notably x86.
So since you're doing this work and given the above pattern is common on
the non iova case, we could save ourselves 2 branches checks on x86 on
__dma_iova_link() and also generalize savings for the non-iova case as
well. For the non-iova case we have two use cases, one with the attrs on
initial mapping, and one without on subsequent sync ops. For the iova
case the attr is always consistently used.
So we could just have something like this:
#ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE
static inline void arch_sync_dma_device(struct device *dev,
phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
{
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_device(paddr, size, dir);
}
static inline void arch_sync_dma_device_attrs(struct device *dev,
phys_addr_t paddr, size_t size,
enum dma_data_direction dir,
unsigned long attrs)
{
if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
arch_sync_dma_for_device(paddr, size, dir);
}
#else
static inline void arch_sync_dma_device(struct device *dev,
phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
{
}
static inline void arch_sync_dma_device_attrs(struct device *dev,
phys_addr_t paddr, size_t size,
enum dma_data_direction dir,
unsigned long attrs)
{
}
#endif
> +/**
> + * dma_iova_link - Link a range of IOVA space
> + * @dev: DMA device
> + * @state: IOVA state
> + * @phys: physical address to link
> + * @offset: offset into the IOVA state to map into
> + * @size: size of the buffer
> + * @dir: DMA direction
> + * @attrs: attributes of mapping properties
> + *
> + * Link a range of IOVA space for the given IOVA state without IOTLB sync.
> + * This function is used to link multiple physical addresses in contiguous
> + * IOVA space without performing costly IOTLB sync.
> + *
> + * The caller is responsible to call to dma_iova_sync() to sync IOTLB at
> + * the end of linkage.
> + */
> +int dma_iova_link(struct device *dev, struct dma_iova_state *state,
> + phys_addr_t phys, size_t offset, size_t size,
> + enum dma_data_direction dir, unsigned long attrs)
> +{
> + struct iommu_domain *domain = iommu_get_dma_domain(dev);
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iova_domain *iovad = &cookie->iovad;
> + size_t iova_start_pad = iova_offset(iovad, phys);
> +
> + if (WARN_ON_ONCE(iova_start_pad && offset > 0))
> + return -EIO;
> +
> + if (dev_use_swiotlb(dev, size, dir) && iova_offset(iovad, phys | size))
There is already a similar check for the non-iova case for this on
iommu_dma_map_page() and a nice comment about what why this checked,
this seems to be just screaming for a helper:
/*
* Checks if a physical buffer has unaligned boundaries with respect to
* the IOMMU granule. Returns non-zero if either the start or end
* address is not aligned to the granule boundary.
*/
static inline size_t iova_unaligned(struct iova_domain *iovad,
phys_addr_t phys,
size_t size)
{
return iova_offset(iovad, phys | size);
}
Other than that, looks good.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Luis
next prev parent reply other threads:[~2025-04-26 22:46 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 8:12 [PATCH v9 00/24] Provide a new two step DMA mapping API Leon Romanovsky
2025-04-23 8:12 ` [PATCH v9 01/24] PCI/P2PDMA: Refactor the p2pdma mapping helpers Leon Romanovsky
2025-04-26 0:21 ` Luis Chamberlain
2025-04-27 7:25 ` Leon Romanovsky
2025-04-23 8:12 ` [PATCH v9 02/24] dma-mapping: move the PCI P2PDMA mapping helpers to pci-p2pdma.h Leon Romanovsky
2025-04-26 0:34 ` Luis Chamberlain
2025-04-27 7:53 ` Leon Romanovsky
2025-04-23 8:12 ` [PATCH v9 03/24] iommu: generalize the batched sync after map interface Leon Romanovsky
2025-04-23 17:15 ` Jason Gunthorpe
2025-04-24 6:55 ` Leon Romanovsky
2025-04-26 0:52 ` Luis Chamberlain
2025-04-27 7:54 ` Leon Romanovsky
2025-04-23 8:12 ` [PATCH v9 04/24] iommu: add kernel-doc for iommu_unmap_fast Leon Romanovsky
2025-04-23 17:15 ` Jason Gunthorpe
2025-04-26 0:55 ` Luis Chamberlain
2025-04-23 8:12 ` [PATCH v9 05/24] dma-mapping: Provide an interface to allow allocate IOVA Leon Romanovsky
2025-04-26 1:10 ` Luis Chamberlain
2025-04-23 8:12 ` [PATCH v9 06/24] iommu/dma: Factor out a iommu_dma_map_swiotlb helper Leon Romanovsky
2025-04-26 1:14 ` Luis Chamberlain
2025-04-23 8:12 ` [PATCH v9 07/24] dma-mapping: Implement link/unlink ranges API Leon Romanovsky
2025-04-26 22:46 ` Luis Chamberlain [this message]
2025-04-27 8:13 ` Leon Romanovsky
2025-04-28 13:16 ` Jason Gunthorpe
2025-04-28 13:20 ` Christoph Hellwig
2025-04-23 8:12 ` [PATCH v9 08/24] dma-mapping: add a dma_need_unmap helper Leon Romanovsky
2025-04-26 22:49 ` Luis Chamberlain
2025-04-23 8:13 ` [PATCH v9 09/24] docs: core-api: document the IOVA-based API Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 10/24] mm/hmm: let users to tag specific PFN with DMA mapped bit Leon Romanovsky
2025-04-23 17:17 ` Jason Gunthorpe
2025-04-23 17:54 ` Mika Penttilä
2025-04-23 18:17 ` Jason Gunthorpe
2025-04-23 18:37 ` Mika Penttilä
2025-04-23 23:33 ` Jason Gunthorpe
2025-04-24 8:07 ` Leon Romanovsky
2025-04-24 8:11 ` Christoph Hellwig
2025-04-24 8:46 ` Leon Romanovsky
2025-04-24 12:07 ` Jason Gunthorpe
2025-04-24 12:50 ` Leon Romanovsky
2025-04-24 16:01 ` Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 11/24] mm/hmm: provide generic DMA managing logic Leon Romanovsky
2025-04-23 17:28 ` Jason Gunthorpe
2025-04-24 7:15 ` Leon Romanovsky
2025-04-24 7:22 ` Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 12/24] RDMA/umem: Store ODP access mask information in PFN Leon Romanovsky
2025-04-23 17:34 ` Jason Gunthorpe
2025-04-23 8:13 ` [PATCH v9 13/24] RDMA/core: Convert UMEM ODP DMA mapping to caching IOVA and page linkage Leon Romanovsky
2025-04-23 17:36 ` Jason Gunthorpe
2025-04-23 8:13 ` [PATCH v9 14/24] RDMA/umem: Separate implicit ODP initialization from explicit ODP Leon Romanovsky
2025-04-23 17:38 ` Jason Gunthorpe
2025-04-23 8:13 ` [PATCH v9 15/24] vfio/mlx5: Explicitly use number of pages instead of allocated length Leon Romanovsky
2025-04-23 17:39 ` Jason Gunthorpe
2025-04-23 8:13 ` [PATCH v9 16/24] vfio/mlx5: Rewrite create mkey flow to allow better code reuse Leon Romanovsky
2025-04-23 18:02 ` Jason Gunthorpe
2025-04-23 8:13 ` [PATCH v9 17/24] vfio/mlx5: Enable the DMA link API Leon Romanovsky
2025-04-23 18:09 ` Jason Gunthorpe
2025-04-24 7:55 ` Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 18/24] block: share more code for bio addition helper Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 19/24] block: don't merge different kinds of P2P transfers in a single bio Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 20/24] blk-mq: add scatterlist-less DMA mapping helpers Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 21/24] nvme-pci: remove struct nvme_descriptor Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 22/24] nvme-pci: use a better encoding for small prp pool allocations Leon Romanovsky
2025-04-23 9:05 ` Christoph Hellwig
2025-04-23 13:39 ` Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 23/24] nvme-pci: convert to blk_rq_dma_map Leon Romanovsky
2025-04-23 9:24 ` Christoph Hellwig
2025-04-23 10:03 ` Leon Romanovsky
2025-04-23 15:47 ` Christoph Hellwig
2025-04-23 17:00 ` Jason Gunthorpe
2025-04-23 15:05 ` Keith Busch
2025-04-27 7:10 ` Leon Romanovsky
2025-04-23 14:58 ` Keith Busch
2025-04-23 17:11 ` Leon Romanovsky
2025-04-23 8:13 ` [PATCH v9 24/24] nvme-pci: store aborted state in flags variable Leon Romanovsky
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=aA1iRtCsPkuprI-X@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=chuck.lever@oracle.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jake@lwn.net \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=joro@8bytes.org \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=sagi@grimberg.me \
--cc=schnelle@linux.ibm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yishaih@nvidia.com \
--cc=zyjzyj2000@gmail.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