From: Robin Murphy <robin.murphy@arm.com>
Cc: Vineet Gupta <vgupta@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Hanjun Guo <guohanjun@huawei.com>,
Sudeep Holla <sudeep.holla@arm.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
iommu@lists.linux.dev, devicetree@vger.kernel.org,
Jason Gunthorpe <jgg@nvidia.com>
Subject: [PATCH v3 5/7] iommu/dma: Make limit checks self-contained
Date: Fri, 9 Feb 2024 16:50:02 +0000 [thread overview]
Message-ID: <2f9fe1c4fd29043db3d61d265bdf9908bb7fa85c.1707493264.git.robin.murphy@arm.com> (raw)
In-Reply-To: <cover.1707493264.git.robin.murphy@arm.com>
It's now easy to retrieve the device's DMA limits if we want to check
them against the domain aperture, so do that ourselves instead of
relying on them being passed through the callchain.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index dbe3c225e0d5..52126f73f690 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -660,19 +660,16 @@ static void iommu_dma_init_options(struct iommu_dma_options *options,
/**
* iommu_dma_init_domain - Initialise a DMA mapping domain
* @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
- * @base: IOVA at which the mappable address space starts
- * @limit: Last address of the IOVA space
* @dev: Device the domain is being initialised for
*
- * @base and @limit + 1 should be exact multiples of IOMMU page granularity to
- * avoid rounding surprises. If necessary, we reserve the page at address 0
+ * If the geometry and dma_range_map include address 0, we reserve that page
* to ensure it is an invalid IOVA. It is safe to reinitialise a domain, but
* any change which could make prior IOVAs invalid will fail.
*/
-static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
- dma_addr_t limit, struct device *dev)
+static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev)
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ const struct bus_dma_region *map = dev->dma_range_map;
unsigned long order, base_pfn;
struct iova_domain *iovad;
int ret;
@@ -684,18 +681,18 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
- base_pfn = max_t(unsigned long, 1, base >> order);
+ base_pfn = 1;
/* Check the domain allows at least some access to the device... */
- if (domain->geometry.force_aperture) {
+ if (map) {
+ dma_addr_t base = dma_range_map_min(map);
if (base > domain->geometry.aperture_end ||
- limit < domain->geometry.aperture_start) {
+ dma_range_map_max(map) < domain->geometry.aperture_start) {
pr_warn("specified DMA range outside IOMMU capability\n");
return -EFAULT;
}
/* ...then finally give it a kicking to make sure it fits */
- base_pfn = max_t(unsigned long, base_pfn,
- domain->geometry.aperture_start >> order);
+ base_pfn = max(base, domain->geometry.aperture_start) >> order;
}
/* start_pfn is always nonzero for an already-initialised domain */
@@ -1746,7 +1743,7 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
* underlying IOMMU driver needs to support via the dma-iommu layer.
*/
if (iommu_is_dma_domain(domain)) {
- if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
+ if (iommu_dma_init_domain(domain, dev))
goto out_err;
dev->dma_ops = &iommu_dma_ops;
}
--
2.39.2.101.g768bb238c484.dirty
next prev parent reply other threads:[~2024-02-09 16:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-09 16:49 [PATCH v3 0/7] dma-mapping: Simplify arch_setup_dma_ops() Robin Murphy
2024-02-09 16:49 ` [PATCH v3 1/7] OF: Retire dma-ranges mask workaround Robin Murphy
2024-02-09 16:49 ` [PATCH v3 2/7] OF: Simplify DMA range calculations Robin Murphy
2024-02-09 16:50 ` [PATCH v3 3/7] ACPI/IORT: Handle memory address size limits as limits Robin Murphy
2024-02-24 11:43 ` Hanjun Guo
2024-02-09 16:50 ` [PATCH v3 4/7] dma-mapping: Add helpers for dma_range_map bounds Robin Murphy
2024-02-24 11:47 ` Hanjun Guo
2024-02-09 16:50 ` Robin Murphy [this message]
2024-02-09 16:50 ` [PATCH v3 6/7] iommu/dma: Centralise iommu_setup_dma_ops() Robin Murphy
2024-02-10 11:27 ` Baolu Lu
2024-03-08 20:37 ` Jason Gunthorpe
2024-02-09 16:50 ` [PATCH v3 7/7] dma-mapping: Simplify arch_setup_dma_ops() Robin Murphy
2024-02-09 19:37 ` Michael Kelley
2024-03-08 20:37 ` Jason Gunthorpe
2024-02-24 11:32 ` [PATCH v3 0/7] " Hanjun Guo
2024-03-06 12:02 ` Robin Murphy
2024-03-06 12:10 ` Christoph Hellwig
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=2f9fe1c4fd29043db3d61d265bdf9908bb7fa85c.1707493264.git.robin.murphy@arm.com \
--to=robin.murphy@arm.com \
--cc=aou@eecs.berkeley.edu \
--cc=baolu.lu@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=decui@microsoft.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=frowand.list@gmail.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=guohanjun@huawei.com \
--cc=haiyangz@microsoft.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=kernel@xen0n.name \
--cc=kys@microsoft.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lpieralisi@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mjrosato@linux.ibm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=sudeep.holla@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tsbogend@alpha.franken.de \
--cc=vgupta@kernel.org \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
/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).