From: Mikko Perttunen <mperttunen@nvidia.com>
To: dri-devel@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org, sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH 05/11] ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains
Date: Tue, 15 Sep 2026 14:59:58 +0900 [thread overview]
Message-ID: <13h4sEdhSdWkep6PrkUEeg@nvidia.com> (raw)
In-Reply-To: <20260915022922.ECC6F1F00893@smtp.kernel.org>
On Tuesday, September 15, 2026 11:29 AM sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] arm: loss of per-device IOVA bounds for core-owned domains in ARM32 IOMMU DMA
> --
>
> commit ebe6429aeb25c05897865b7deefe9f71d234666a
> Author: Mikko Perttunen <mperttunen@nvidia.com>
>
> ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains
>
> This commit updates the ARM DMA mapping logic to bypass custom IOMMU domain
> management when a core-owned DMA default domain is requested. It adds checks
> in arm_setup_iommu_dma_ops() and arm_teardown_iommu_dma_ops() to skip legacy
> initialization and teardown steps if an existing cookie indicates core
> ownership.
>
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index e0d58778c5f54..91f12fb91509e 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -1761,9 +1761,18 @@ EXPORT_SYMBOL_GPL(arm_iommu_detach_device);
> >
> > static void arm_setup_iommu_dma_ops(struct device *dev)
> > {
> > - struct dma_iommu_mapping *mapping;
> > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> > u64 dma_base = 0, size = 1ULL << 32;
> >
> > + /*
> > + * An existing cookie means the core owns the domain. Only set the
> > + * per-binding DMA ops.
> > + */
> > + if (mapping) {
> > + set_dma_ops(dev, &iommu_ops);
> > + return;
> > + }
> > +
> > if (dev->dma_range_map) {
>
> [Severity: High]
> Does this early return cause core-owned domains to bypass the legacy logic
> that extracts and applies per-device dma_range_map constraints to the IOVA
> space?
>
> If a device specifies a dma-ranges property in DT and operates under an
> IOMMU driver that opts into the IOMMU_DOMAIN_DMA default domain, it seems
> this early return bypasses the custom mapping initialization that previously
> baked the dma_range_map constraints into mapping->base and mapping->size.
>
> When iommu_ops.alloc is called, won't the ARM32 legacy allocator
> __alloc_iova() assign IOVAs based solely on the generic IOMMU aperture
> geometry, ignoring these device-specific constraints?
Ack, will look into this for v2. FWIW, on Tegra (and thus any device
affected by the series) this doesn't matter.
Thanks
Mikko
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260915-b4-arm32-iommu-dma-cookie-v1-0-ba4f9d33a2b8@nvidia.com?part=5
next prev parent reply other threads:[~2026-09-15 6:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260915021542eucas1p254addab18c10cb117f42ccf3d3522883@eucas1p2.samsung.com>
2026-09-15 2:14 ` [PATCH 00/11] Make the 32-bit ARM DMA API work with normal IOMMU DMA default domains (+ Tegra PoC) Mikko Perttunen
2026-09-15 2:14 ` [PATCH 01/11] iommu: Add iommu_teardown_dma_ops Mikko Perttunen
2026-09-15 2:14 ` [PATCH 02/11] iommu: Add cookie type for ARM_DMA_USE_IOMMU Mikko Perttunen
2026-09-15 2:14 ` [PATCH 03/11] ARM: dma-mapping: Split mapping allocation from domain allocation Mikko Perttunen
2026-09-15 2:14 ` [PATCH 04/11] ARM: dma-mapping: Implement and expose DMA setup functions Mikko Perttunen
2026-09-15 2:15 ` [PATCH 05/11] ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains Mikko Perttunen
2026-09-15 2:29 ` sashiko-bot
2026-09-15 5:59 ` Mikko Perttunen [this message]
2026-09-15 2:15 ` [PATCH 06/11] ARM: dma-mapping: Handle foreign buffers in arm_iommu_get_sgtable Mikko Perttunen
2026-09-15 2:15 ` [PATCH 07/11] iommu: Let 32-bit ARM drivers opt into a DMA API default domain Mikko Perttunen
2026-09-15 2:15 ` [PATCH 08/11] iommu/tegra-smmu: Defer display client translation to driver handover Mikko Perttunen
2026-09-15 2:32 ` sashiko-bot
2026-09-15 6:02 ` Mikko Perttunen
2026-09-15 2:15 ` [PATCH 09/11] gpu: host1x: Drop release of legacy 32-bit ARM DMA domain Mikko Perttunen
2026-09-15 2:15 ` [PATCH 10/11] drm/tegra: " Mikko Perttunen
2026-09-15 2:15 ` [PATCH 11/11] iommu/tegra-smmu: Use a DMA API default domain per swgroup Mikko Perttunen
2026-09-25 15:20 ` [PATCH 00/11] Make the 32-bit ARM DMA API work with normal IOMMU DMA default domains (+ Tegra PoC) Marek Szyprowski
2026-09-29 7:28 ` Mikko Perttunen
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=13h4sEdhSdWkep6PrkUEeg@nvidia.com \
--to=mperttunen@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/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