All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Peng Fan <peng.fan@oss.nxp.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	"Joerg Roedel (AMD)" <joro@8bytes.org>,
	Will Deacon <will@kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH RFC 0/2] iommu/dma: Fix DMA_ATTR_MMIO swiotlb rejection
Date: Fri, 18 Sep 2026 18:49:59 +0300	[thread overview]
Message-ID: <20260918154959.GZ13683@unreal> (raw)
In-Reply-To: <aq1GyO3vv8W6Adlr@shlinux89>

On Fri, Sep 18, 2026 at 10:12:24PM +0800, Peng Fan wrote:
> Hi Leon,
> 
> On Fri, Sep 18, 2026 at 03:37:36PM +0300, Leon Romanovsky wrote:
> >On Wed, Sep 16, 2026 at 11:23:32PM +0800, Peng Fan (OSS) wrote:
> >> Commit f9374de14c0e8 ("iommu/dma: implement DMA_ATTR_MMIO for
> >> iommu_dma_(un)map_phys()") and commit c288d657dd515 ("iommu/dma: implement
> >> DMA_ATTR_MMIO for dma_iova_link().") added DMA_ATTR_MMIO support to skip
> >> swiotlb bouncing and cache flushing for MMIO resources. However, both
> >> implementations placed the DMA_ATTR_MMIO check inside the swiotlb bounce block,
> >> causing non-page-aligned MMIO mappings to be rejected outright instead of
> >> skipping the bounce and proceeding to create the IOVA mapping.
> >> 
> >> This breaks dma_map_resource() for any non-page-aligned device register when
> >> behind an IOMMU: DMA controllers that map peripheral FIFO addresses
> >> (e.g. SPI controller TX/RX data registers) through an IOMMU for per-channel
> >> isolation.
> >> 
> >> Both patches move the DMA_ATTR_MMIO check before the swiotlb block so MMIO,
> >> resources skip the entire bounce path and fall through directly to the IOMMU
> >> mapping function.
> >
> >While I understand the rationale behind the first patch, why do we need the
> >second one? Do we want to allow unaligned addresses for the _link_ as well?
> >Current users don't need it.
> 
> My intention with the second patch was to make the DMA_ATTR_MMIO handling
> consistent with iommu_dma_map_phys(), since MMIO cannot be bounced by
> SWIOTLB in either case.
> 
> However, I don't have a dma_iova_link() user that requires an
> unaligned MMIO address, so no need to relax the existing restriction there.
>  
> I'll drop the second patch and keep this fix scoped to iommu_dma_map_phys()
> in v2. Does that sounds good to you?
> 
> BTW, does patch 1 look good to you?

Yes, for both questions.

Thanks

> 
> Thanks,
> Peng
> 
> >
> >Thanks
> >
> >> 
> >> Tested on NXP i.MX95 with ARM SMMUv3 where the fsl-edma DMA controller maps
> >> SPI peripheral FIFO registers (non-page-aligned) via dma_map_resource()
> >> through per-channel IOMMU domains. Only the iommu_dma_map_phys() path was
> >> exercised; the dma_iova_link() fix is by code inspection of the same pattern.
> >> 
> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >> ---
> >> Peng Fan (2):
> >>       iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys
> >>       iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in dma_iova_link()
> >> 
> >>  drivers/iommu/dma-iommu.c | 8 ++++----
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >> ---
> >> base-commit: e6e35979777d646fe3c7c94dca7dd32fb25d45f4
> >> change-id: 20260916-iommu-dma-fix-9f55af1beb46
> >> 
> >> Best regards,
> >> --  
> >> Peng Fan <peng.fan@nxp.com>
> >> 
> >> 
> >
> >
> 

      parent reply	other threads:[~2026-09-18 15:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 15:23 [PATCH RFC 0/2] iommu/dma: Fix DMA_ATTR_MMIO swiotlb rejection Peng Fan (OSS)
2026-09-16 15:23 ` [PATCH RFC 1/2] iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys Peng Fan (OSS)
2026-09-18 14:37   ` Robin Murphy
2026-09-23  7:58   ` Marek Szyprowski
2026-09-16 15:23 ` [PATCH RFC 2/2] iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in dma_iova_link() Peng Fan (OSS)
2026-09-18 12:37 ` [PATCH RFC 0/2] iommu/dma: Fix DMA_ATTR_MMIO swiotlb rejection Leon Romanovsky
2026-09-18 14:12   ` Peng Fan
2026-09-18 15:43     ` Marek Szyprowski
2026-09-18 15:49     ` Leon Romanovsky [this message]

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=20260918154959.GZ13683@unreal \
    --to=leon@kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=robin.murphy@arm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.