From: Leon Romanovsky <leon@kernel.org>
To: Jens Axboe <axboe@kernel.dk>, Jason Gunthorpe <jgg@ziepe.ca>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>
Cc: "Leon Romanovsky" <leonro@nvidia.com>,
"Keith Busch" <kbusch@kernel.org>,
"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>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Jonathan Corbet" <corbet@lwn.net>,
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
Subject: [PATCH 05/18] dma: Provide an interface to allow allocate IOVA
Date: Sun, 27 Oct 2024 16:21:05 +0200 [thread overview]
Message-ID: <844f3dcf9c341b8178bfbc90909ef13d11dd2193.1730037276.git.leon@kernel.org> (raw)
In-Reply-To: <cover.1730037276.git.leon@kernel.org>
From: Leon Romanovsky <leonro@nvidia.com>
The existing .map_page() callback provides both allocating of IOVA
and linking DMA pages. That combination works great for most of the
callers who use it in control paths, but is less effective in fast
paths where there may be multiple calls to map_page().
These advanced callers already manage their data in some sort of
database and can perform IOVA allocation in advance, leaving range
linkage operation to be in fast path.
Provide an interface to allocate/deallocate IOVA and next patch
link/unlink DMA ranges to that specific IOVA.
The API is exported from dma-iommu as it is the only implementation
supported, the namespace is clearly different from iommu_* functions
which are not allowed to be used. This code layout allows us to save
function call per API call used in datapath as well as a lot of boilerplate
code.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/iommu/dma-iommu.c | 79 +++++++++++++++++++++++++++++++++++++
include/linux/dma-mapping.h | 15 +++++++
2 files changed, 94 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c422e36c0d66..0644152c5aad 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1745,6 +1745,85 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
return SIZE_MAX;
}
+static bool iommu_dma_iova_alloc(struct device *dev,
+ struct dma_iova_state *state, phys_addr_t phys, size_t size)
+{
+ 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_off = iova_offset(iovad, phys);
+ dma_addr_t addr;
+
+ if (WARN_ON_ONCE(!size))
+ return false;
+ if (WARN_ON_ONCE(size & DMA_IOVA_USE_SWIOTLB))
+ return false;
+
+ addr = iommu_dma_alloc_iova(domain,
+ iova_align(iovad, size + iova_off),
+ dma_get_mask(dev), dev);
+ if (!addr)
+ return false;
+
+ state->addr = addr + iova_off;
+ state->__size = size;
+ return true;
+}
+
+/**
+ * dma_iova_try_alloc - Try to allocate an IOVA space
+ * @dev: Device to allocate the IOVA space for
+ * @state: IOVA state
+ * @phys: physical address
+ * @size: IOVA size
+ *
+ * Check if @dev supports the IOVA-based DMA API, and if yes allocate IOVA space
+ * for the given base address and size.
+ *
+ * Note: @phys is only used to calculate the IOVA alignment. Callers that always
+ * do PAGE_SIZE aligned transfers can safely pass 0 here.
+ *
+ * Returns %true if the IOVA-based DMA API can be used and IOVA space has been
+ * allocated, or %false if the regular DMA API should be used.
+ */
+bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
+ phys_addr_t phys, size_t size)
+{
+ memset(state, 0, sizeof(*state));
+ if (!use_dma_iommu(dev))
+ return false;
+ if (static_branch_unlikely(&iommu_deferred_attach_enabled) &&
+ iommu_deferred_attach(dev, iommu_get_domain_for_dev(dev)))
+ return false;
+ return iommu_dma_iova_alloc(dev, state, phys, size);
+}
+EXPORT_SYMBOL_GPL(dma_iova_try_alloc);
+
+/**
+ * dma_iova_free - Free an IOVA space
+ * @dev: Device to free the IOVA space for
+ * @state: IOVA state
+ *
+ * Undoes a successful dma_try_iova_alloc().
+ *
+ * Note that all dma_iova_link() calls need to be undone first. For callers
+ * that never call dma_iova_unlink(), dma_iova_destroy() can be used instead
+ * which unlinks all ranges and frees the IOVA space in a single efficient
+ * operation.
+ */
+void dma_iova_free(struct device *dev, struct dma_iova_state *state)
+{
+ 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, state->addr);
+ size_t size = dma_iova_size(state);
+
+ iommu_dma_free_iova(cookie, state->addr - iova_start_pad,
+ iova_align(iovad, size + iova_start_pad), NULL);
+}
+EXPORT_SYMBOL_GPL(dma_iova_free);
+
void iommu_setup_dma_ops(struct device *dev)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 6075e0708deb..817f11bce7bc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -11,6 +11,7 @@
#include <linux/scatterlist.h>
#include <linux/bug.h>
#include <linux/mem_encrypt.h>
+#include <linux/iommu.h>
/**
* List of possible attributes associated with a DMA mapping. The semantics
@@ -77,6 +78,7 @@
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
struct dma_iova_state {
+ dma_addr_t addr;
size_t __size;
};
@@ -307,11 +309,24 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
{
return state->__size != 0;
}
+
+bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
+ phys_addr_t phys, size_t size);
+void dma_iova_free(struct device *dev, struct dma_iova_state *state);
#else /* CONFIG_IOMMU_DMA */
static inline bool dma_use_iova(struct dma_iova_state *state)
{
return false;
}
+static inline bool dma_iova_try_alloc(struct device *dev,
+ struct dma_iova_state *state, phys_addr_t phys, size_t size)
+{
+ return false;
+}
+static inline void dma_iova_free(struct device *dev,
+ struct dma_iova_state *state)
+{
+}
#endif /* CONFIG_IOMMU_DMA */
#if defined(CONFIG_HAS_DMA) && defined(CONFIG_DMA_NEED_SYNC)
--
2.46.2
next prev parent reply other threads:[~2024-10-27 14:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-27 14:21 [PATCH 00/18] Provide a new two step DMA mapping API Leon Romanovsky
2024-10-27 14:21 ` [PATCH 01/18] PCI/P2PDMA: refactor the p2pdma mapping helpers Leon Romanovsky
2024-10-28 18:10 ` Logan Gunthorpe
2024-10-28 20:59 ` Bjorn Helgaas
2024-10-29 16:48 ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 02/18] dma-mapping: move the PCI P2PDMA mapping helpers to pci-p2pdma.h Leon Romanovsky
2024-10-28 18:11 ` Logan Gunthorpe
2024-10-29 15:11 ` Bjorn Helgaas
2024-10-27 14:21 ` [PATCH 03/18] iommu: generalize the batched sync after map interface Leon Romanovsky
2024-10-27 14:21 ` [PATCH 04/18] dma-mapping: Add check if IOVA can be used Leon Romanovsky
2024-10-27 14:21 ` Leon Romanovsky [this message]
2024-10-28 1:24 ` [PATCH 05/18] dma: Provide an interface to allow allocate IOVA Baolu Lu
2024-10-28 6:37 ` Leon Romanovsky
2024-10-29 7:46 ` Christoph Hellwig
2024-10-28 4:24 ` Srinivasulu Thanneeru
2024-10-28 6:46 ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 06/18] iommu/dma: Factor out a iommu_dma_map_swiotlb helper Leon Romanovsky
2024-10-27 14:21 ` [PATCH 07/18] dma-mapping: Implement link/unlink ranges API Leon Romanovsky
2024-10-28 2:00 ` Baolu Lu
2024-10-28 6:22 ` Leon Romanovsky
2024-10-28 18:31 ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 08/18] dma-mapping: add a dma_need_unmap helper Leon Romanovsky
2024-10-27 14:21 ` [PATCH 09/18] docs: core-api: document the IOVA-based API Leon Romanovsky
2024-10-28 18:12 ` Logan Gunthorpe
2024-10-28 18:28 ` Leon Romanovsky
2024-10-27 14:21 ` [PATCH 10/18] mm/hmm: let users to tag specific PFN with DMA mapped bit Leon Romanovsky
2024-10-27 14:21 ` [PATCH 11/18] mm/hmm: provide generic DMA managing logic Leon Romanovsky
2024-10-27 14:21 ` [PATCH 12/18] RDMA/umem: Store ODP access mask information in PFN Leon Romanovsky
2024-10-27 14:21 ` [PATCH 13/18] RDMA/core: Convert UMEM ODP DMA mapping to caching IOVA and page linkage Leon Romanovsky
2024-10-27 14:21 ` [PATCH 14/18] RDMA/umem: Separate implicit ODP initialization from explicit ODP Leon Romanovsky
2024-10-27 14:21 ` [PATCH 15/18] vfio/mlx5: Explicitly use number of pages instead of allocated length Leon Romanovsky
2024-10-27 14:21 ` [PATCH 16/18] vfio/mlx5: Rewrite create mkey flow to allow better code reuse Leon Romanovsky
2024-10-27 14:21 ` [PATCH 17/18] vfio/mlx5: Explicitly store page list Leon Romanovsky
2024-10-27 14:21 ` [PATCH 18/18] vfio/mlx5: Convert vfio to use DMA link API 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=844f3dcf9c341b8178bfbc90909ef13d11dd2193.1730037276.git.leon@kernel.org \
--to=leon@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=joro@8bytes.org \
--cc=kbusch@kernel.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.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=shameerali.kolothum.thodi@huawei.com \
--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).