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

[Vivian Wang]

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.
>
>