[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