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

[Zong Li]

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.

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.

> Thanks,
> Pei
>