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

Guo Ren guoren at kernel.org
Tue Jun 16 08:47:05 PDT 2026


On Tue, Jun 16, 2026 at 6:36 PM David Laight
<david.laight.linux at gmail.com> wrote:
>
> On Mon, 15 Jun 2026 12:38:17 +0000
> Guo Ren <guoren at kernel.org> wrote:
>
> > Hi Zhanpeng Zhang,
> ..
> > 3. Only performance-monitoring counters require 64-bit IO access or the
> > high-low-high do-while retry strategy. For ordinary status and control
> > MMIO registers, a single read is sufficient.
>
> Actually this sequence should be enough for a counter:
>         hi = read_hi();
>         lo = read_lo();
>         if (hi != read_hi()) {
>                 // Pick a value that happened while doing the reads.
>                 hi++;
>                 lo = 0;
>         }
This is not a free optimization — it does not preserve the same
semantics as an atomic 64-bit read. There are at least two correctness
issues:

1. Loss of precision: If hi changed during the read, setting lo = 0
discards the actual lo value. The correct approach is to re-read lo
after detecting the change, not fabricate a value.

2. Multiple overflows: This assumes at most one overflow occurs
between reads. If two overflows happen (e.g., due to interrupt
injection), hi++ will produce an incorrect result, silently corrupting
the counter value.

Negligible benefit: hi changing between reads is an extremely rare
event. Optimizing away the retry loop for such a rare case provides no
meaningful performance gain. And if hi never stabilizes, that
indicates a hardware failure — in which case hanging in the retry loop
is actually the more appropriate behavior, as it makes the failure
visible rather than silently producing garbage values.

The high-low-high do-while retry strategy exists precisely to handle
these cases correctly. I don't think this proposed sequence is a valid
replacement.

-- 
Best Regards
 Guo Ren



More information about the linux-riscv mailing list