[PATCH v1] iommu/riscv: Support 32-bit register accesses

[Guo Ren]

Hi Vivian,

As noted in the RISC-V IOMMU Specification, Chapter 6:
> Whether an 8-byte access to an IOMMU register is single-copy atomic is UNSPECIFIED, and such an access may appear, internally to the IOMMU, as if two separate 4-byte accesses — first to the high half and second to the low half — were performed.

Therefore, the atomicity of 64-bit MMIO accesses is UNSPECIFIED and
not clearly defined in the current ratified RISC-V IOMMU
specification. To handle this correctly, the Linux RISC-V IOMMU driver
should fall back to 32-bit MMIO accesses when reading 64-bit registers
(e.g., performance counters). The behavior of 32-bit MMIO accesses is
more precisely defined in the RISC-V IOMMU specification.

Thus, many hardware vendors implement 32-bit MMIO (rather than 64-bit
MMIO) based on the current ratified RISC-V IOMMU specification, and
this driver does not appear to benefit from 64-bit MMIO access either.
Performance is fundamentally constrained by bus latency; assuming that
simply reducing the number of accesses will improve performance is an
oversimplification that ignores the underlying hardware
characteristics.

Hi Zhang,

The hardware targeted by the 32-bit MMIO access in your patch is
precisely the kind that deserves the official ACPI HID RSCV0004 and
Devicetree compatible string (riscv,iommu). It is rather the hardware
that supports only 64-bit MMIO access — whose atomicity is explicitly
left as UNSPECIFIED by the RISC-V IOMMU specification — that should be
relegated to a non-standard ACPI ID. That is what truly constitutes
poor hardware design.

I will consistently support your position of adopting 32-bit MMIO
access in this patch, and will advocate for making it the default
behavior in the Linux RISC-V IOMMU driver, as it better aligns with
the intent of the RISC-V IOMMU specification.

--
Best Regards
 Guo Ren

On Thu, Jun 18, 2026 at 3:33 PM Vivian Wang <wangruikang at iscas.ac.cn> wrote:
>
> On 6/18/26 11:45, Guo Ren wrote:
> > On Thu, Jun 18, 2026 at 11:20 AM Vivian Wang <wangruikang at iscas.ac.cn> wrote:
> >> On 6/15/26 20:38, Guo Ren wrote:
> >>> Hi Zhanpeng Zhang,
> >>>
> >>> I noticed you posted a similar fix recently. However, I had already
> >>> submitted a similar solution back in September 2025 [1]. It would be
> >>> great if you could review it. A few concerns with the current patch:
> >>>
> >>> 1. Using spin_lock_irqsave in such a small semantic structure is
> >>> unnecessary. IRQ protection should be provided by the higher-level
> >>> IOMMU driver interfaces. Many existing call sites already handle IRQ
> >>> disabling, so adding it here feels redundant and adds avoidable
> >>> overhead.
> >>>
> >>> 2. More critically, the RISCV_IOMMU_32BIT_ACCESS Kconfig option is
> >>> problematic. According to the RISC-V IOMMU specification (Software
> >>> Guidelines, “Reading and writing IOMMU registers”):
> >>>
> >>>> Registers that are 64-bit wide may be accessed using either a 32-bit
> >>>> or a 64-bit access.
> >>> This clearly requires that any hardware supporting 64-bit MMIO access
> >>> must also support 32-bit MMIO access. Therefore, the IOMMU driver should
> >>> be built on a 32-bit access base for maximum hardware compatibility.
> >> I agree that the driver should be build with 32-bit accesses to support
> >> these hardware. However there's one minor thing that I want to propose
> >> regarding this, for the sake of clarity:
> >>
> >> RISC-V IOMMU implementations that do not support 64-bit accesses are not
> >> fully compliant with the RISC-V IOMMU specification and should not use
> >> the standard RISC-V identifiers, namely:
> >>
> >> - Devicetree compatible riscv,iommu
> >> - ACPI HID RSCV0004
> >>
> >> This, in my opinion, is not only the right thing to do (not claiming to
> >> be standard hardware without actually being standard hardware), but also
> >> saves a lot of trouble for operating system developers (yes, there are
> >> RISC-V operating systems other than Linux out there), since invalid IO
> >> accesses usually manifest as mysterious access faults (that would
> >> usually suggest an incorrect IOMMU address), or worse, system hangs.
> >>
> >> I would appreciate if the hardware vendors shipping 32-bit-access-only
> >> IOMMUs would consider this.
> >>
> >> Vivian "dramforever" Wang
> >>
> > 32-bit MMIO access is explicitly supported by the RISC-V IOMMU
> > specification and is a valid choice (64-bit MMIO access is optional).
>
> Hmm... I think it's optional in software but not optional in hardware,
> but the specs are not super clear on this. I've opened a GitHub issue to
> ask:
>
>     https://github.com/riscv-non-isa/riscv-iommu/issues/765
>
> > 64-bit MMIO access is not "free" — it consumes additional interconnect
> > hardware resources.
> >
> > Could you elaborate on the concrete benefit of using 64-bit MMIO
> > access in this driver, for these non-PMU registers? A clear
> > justification would help evaluate whether the trade-off is worthwhile.
> >
> >
>