[PATCH v3] iommu/riscv: Use 32-bit MMIO accesses for 64-bit registers

[Guo Ren]

On Thu, Jul 16, 2026 at 2:59 PM Zong Li <zong.li at sifive.com> wrote:
>
> On Thu, Jul 16, 2026 at 12:04 PM Guo Ren <guoren at kernel.org> wrote:
> >
> > On Thu, Jul 16, 2026 at 11:13 AM Zong Li <zong.li at sifive.com> wrote:
> > >
> > > On Wed, Jul 15, 2026 at 5:43 PM Chen Pei <cp0613 at linux.alibaba.com> wrote:
> > > >
> > > > On Tue, Jul 14, 2026 at 09:55:19PM +0800, Guo Ren wrote:
> > > > > The specification is deliberately precise. It uses "may", not "shall"
> > > > > or "must". We should not introduce speculative implications that break
> > > > > the spec's consistency on RV32. The safe and portable interpretation
> > > > > is that software is explicitly allowed to use 32-bit accesses for
> > > > > these registers on any system, which is exactly what this patch does.
> > > >
> > > > The RV32 argument is quite compelling. The RISC-V IOMMU is a
> > > > platform-level IP that must serve both RV32 and RV64 software stacks.
> > > > Mandating 64-bit MMIO accesses would directly conflict with RV32, where
> > > > such accesses are impossible — so any interpretation that turns "may be
> > > > accessed using either a 32-bit or a 64-bit access" into an implicit
> > > > hardware requirement for 64-bit accesses breaks the spec's own
> > > > consistency on RV32.
> > > >
> > > > The RFC 2119 argument is equally strong. In RFC 2119 terms, "MAY" means
> > > > an item is truly optional — a specification should express obligations
> > > > through these well-defined normative keywords, not leave them to be
> > > > inferred from everyday-language intuition. If the spec authors had
> > > > intended to require hardware to support 64-bit accesses, they would have
> > > > said "must" or "shall".
> > > >
> > > > Given both points, treating 32-bit MMIO accesses as the default for the
> > > > RISC-V IOMMU driver is the safe, portable, and more inclusive choice: it
> > > > is explicitly permitted on every conformant implementation, whereas
> > > > 64-bit access atomicity is left unspecified.
> > > >
> > > > Acked-by: Chen Pei <cp0613 at linux.alibaba.com>
> > > >
> > >
> > > It seems that we might not need to worry about RV32. The
> > > io-64-nonatomic-hi-lo.h header will automatically replace writeq/readq
> > > with hi_lo_writeq/readq in RV32 build. Therefore, perhaps we can just
> > > focus our discussion on RV64: whether the driver should use
> > > readq/writeq to access 64-bit registers on RV64 systems.
> >
> > The RV32 argument here concerns the interpretation of the
> > specification, not the Linux implementation. Some people interpret the
>
> Yes. However, since these patches are indeed trying to modify the
> Linux implementation, we might not need to worry about this here. On
> RV32, regardless of whether the IOMMU hardware supports native 64-bit
> MMIO accesses, Linux automatically uses two 4-byte accesses for 64-bit
> registers.

The RV32 argument highlights a logical inconsistency in interpreting
“Registers that are 64-bit wide may be accessed using either a 32-bit
or a 64-bit access” as implying that hardware must support native
64-bit MMIO accesses.

Please note that an IOMMU is a platform-level device and is not
inherently tied to either RV32 or RV64. It may be accessed by any bus
master in the system. RV32 is cited here not to discuss how Linux
implements these accesses, but to demonstrate that an unconditional
requirement for the hardware to support native 64-bit MMIO accesses
would be logically inconsistent.


>
> > statement, “Registers that are 64-bit wide may be accessed using
> > either a 32-bit or a 64-bit access,” as imposing an obligation on
> > every hardware implementation to support native 64-bit MMIO accesses.
> > However, RV32 provides a direct counterexample that undermines the
> > validity of this interpretation. The IOMMU is a platform-level
> > component that may be controlled either by an RV32 MCU running an RTOS
> > or by an RV64 processor running Linux. On an RV32 platform, software
> > can access a 64-bit register only through multiple 32-bit
> > transactions. How, then, can this sentence be interpreted as
> > unconditionally requiring the hardware to support native 64-bit MMIO
> > accesses?
> >
> > Moreover, even if “may” is interpreted in the RFC 2119 sense, MAY does
> > not impose a mandatory requirement. We should therefore avoid
> > inferring hardware obligations from assumptions or implications that
> > are not explicitly stated in the specification.
> >
> > >
> > > Actually, in my previous IOMMU PMU series, I shared a similar view to Robin's:
> > > "Revisiting the spec regarding the UNSPECIFIED 8-byte atomic access,
> > > this might imply that the hardware itself will handle the split into
> > > two 4-byte accesses and internally manage its own trigger logic.
> > > Because of this, for RV64 systems, software might simply use standard
> > > 8-byte writes (e.g., writeq). Delegating the access handling to the
> > > hardware is likely the best way to maximize compatibility across all
> > > vendor implementations."
> > > More details: https://lists.infradead.org/pipermail/linux-riscv/2026-July/094099.html
> > >
> > > I also checked the GitHub discussions. The IOMMU spec author seems to
> > > have clarified that the hardware should be able to handle naturally
> > > aligned 64-bit accesses from the software.
> > > More details: https://github.com/riscv-non-isa/riscv-iommu/issues/765
> > >
> > > From my perspective, since the author has already clarified the
> > > intent, it might be better for us to focus on improving and updating
> > > the spec to make it clearer. This could be a better approach than
> > > changing the driver to fit an unclear spec.
> > > What does everyone think about this? If we all agree, I would be happy
> > > to send a new version of the IOMMU PMU series using 64-bit accesses
> > > again for RV64.
> >
> > This issue has already become highly contentious and directly affects
> > real hardware implementations. Any attempt to revise the specification
> > must first clarify whether the current wording actually mandates
> > support for 64-bit MMIO accesses. If the specification is unclear on
> > this point, then no such mandatory requirement can reasonably be
> > imposed on existing hardware implementations.
> >
>
> Yes, I agree. That is why I think we might focus on making the spec
> clearer before changing the driver. Would it make sense to continue
> the discussion on IOMMU spec GitHub? Perhaps reopen the same issue or
> create a new one.

I agree that the issue should be reopened. However, I do not think it
should necessarily block this patch, since it makes the driver use the
32-bit MMIO access path explicitly supported by the current
specification. The correctness of the patch can be reviewed based on
the required access ordering and register-specific semantics,
independently of the broader discussion about mandatory support for
64-bit MMIO transactions.

If the current specification does not clearly establish a mandatory
requirement for 64-bit MMIO accesses, any future clarification should
avoid retroactively invalidating existing implementations that were
built according to a reasonable reading of the current text.

If support for 64-bit MMIO transactions is intended to be optional,
that capability could be explicitly defined, along with an appropriate
mechanism for software to discover it.

Making such support unconditionally mandatory through a later
specification change would require careful consideration of the
compatibility impact on existing hardware.

--
Best Regards
 Guo Ren