From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
David Woodhouse <dwmw2@infradead.org>,
iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Tomasz Jeznach <tjeznach@rivosinc.com>,
Will Deacon <will@kernel.org>,
patches@lists.linux.dev
Subject: Re: [PATCH] iommu/dma: Always allow DMA-FQ when iommupt provides the iommu_domain
Date: Wed, 1 Apr 2026 10:13:49 -0300 [thread overview]
Message-ID: <20260401131349.GA310919@nvidia.com> (raw)
In-Reply-To: <ce5c6be3-0a59-498b-ac0d-eb0dbc1530f6@arm.com>
On Wed, Apr 01, 2026 at 01:53:05PM +0100, Robin Murphy wrote:
> On 2026-03-26 7:30 pm, Jason Gunthorpe wrote:
> > iommupt always supports the semantics required for DMA-FQ, when drivers
> > are converted to use it they automatically get support.
> >
> > Detect iommpt directly instead of using IOMMU_CAP_DEFERRED_FLUSH and
> > remove IOMMU_CAP_DEFERRED_FLUSH from converted drivers.
> >
> > This will also enable DMA-FQ on RISC-V.
>
> I'd much prefer to just add the cap to the RISC-V driver so it's obvious,
> rather than deliberately introduce a fiddly inconsistency. Besides, having
> iommu-dma poke directly at driver-specific internal implementation details
> seems exactly the kind of layering violation you're normally the first to
> object to.
I don't view it as a "driver-specific internal" - generic pt is part
of the core API surface. It is fine to have it and the core code be
coupled together. So I don't like bouncing through the driver to get
information the core already has direct access to...
Like the map/unmap flow run differently now for generic pt and I think
we will keep building things in. My intention is that generic pt will
be mandatory to access certain new features and functions.
But I don't care so much, we can't eliminate IOMMU_CAP_DEFERRED_FLUSH
entirely, this would have just contained it to the para-virt drivers
that can never use generic pt.
> Note that IOMMU_CAP_CACHE_COHERENCY is also arguably a property of
> generic_pt, in as much as all its users are default-coherent with
> IOMMU_CACHE implied, but again RISC_V doesn't report that where AMD and
> Intel do.
Hmm.. Currently generic_pt doesn't have any idea if IOMMU_CACHE is
supported and working in HW. All the implemented formats ignore
IOMMU_CACHE entirely, they use IOMMU_MMIO to build any any non-caching
PTE.
SMMUv3 will be unlike the other three and needs
IOMMU_CAP_CACHE_COHERENCY. IDK if ARM should be writing non-caching
PTEs for non-coherent DMA, it doesn't now..
RISCV does seem to have some gap here.
Jason
next prev parent reply other threads:[~2026-04-01 13:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 19:30 [PATCH] iommu/dma: Always allow DMA-FQ when iommupt provides the iommu_domain Jason Gunthorpe
2026-03-31 7:47 ` Tian, Kevin
2026-04-01 12:53 ` Robin Murphy
2026-04-01 13:13 ` Jason Gunthorpe [this message]
2026-04-03 9:16 ` Will Deacon
2026-04-03 18:36 ` Jason Gunthorpe
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=20260401131349.GA310919@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=patches@lists.linux.dev \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tjeznach@rivosinc.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.