Re: [PATCH v6 2/6] riscv: build kernel atomics from LR/SC when Zaamo is disabled

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]

On Tue, Nov 10, 2026 at 03:20:59PM +0200, Vladimir Kondratiev wrote:
> The A extension is Zaamo plus Zalrsc. On some CPUs Zaamo is present
> only formally. MIPS P8700 traps every AMO instruction into M-mode and
> emulates it there, so the extension is supported but very slow. A
> typical uncontended atomic increment costs:
> 
>   native AMO                                     2..5 cycles
>   LR/SC, private L1 reservation monitor         6..12 cycles
>   LR/SC, PoC (L2) reservation monitor       about 40 cycles
>   AMO emulated by an M-mode trap           about 600 cycles
> 
> The last two were measured on the eyeq7h hardware. On such a CPU the
> kernel must use LR/SC for every atomic.
> 
> Add RISCV_ISA_ZAAMO, default y. The default keeps "a" in -march and
> the generated code unchanged. When it is disabled, -march carries
> _zalrsc instead of "a", and atomic_*, bitops, xchg, futex and the
> early boot code use LR/SC loops. The sequence is chosen with the
> preprocessor, on CONFIG_RISCV_ISA_ZAAMO like the other ISA options in
> the headers, because the assembler rejects AMO mnemonics once -march
> lacks Zaamo. A kernel built this way runs on any hart that implements
> A; it just does not use AMO. It is therefore a plain option, not a
> NONPORTABLE one, and the hart keeps advertising "a" to userspace,
> which is true.
> 
> The LR/SC loops follow the ordering convention of the existing ones
> in cmpxchg.h, from commit 5ce6c1f3535f ("riscv/atomic: Strengthen
> implementations with fences") and commit 1d84afaf0252 ("riscv: Fix
> fully ordered LR/SC xchg[8|16]() implementations"): a fully ordered
> operation is lr, sc.rl and a trailing fence rw,rw; acquire is lr.aq
> with a plain sc; release is a plain lr with sc.rl. The futex loop is
> bounded to 128 retries and returns -EAGAIN after that, as arm64 does,
> because userspace can keep the word changing from another thread and
> futex_wake_op() retries on -EAGAIN anyway.
> 
> Zabha, Zacas and the ssamoswap instruction of Zicfiss are AMO
> instructions, so RISCV_ISA_ZABHA, RISCV_ISA_ZACAS and RISCV_USER_CFI
> depend on RISCV_ISA_ZAAMO. The riscv64imac Rust target emits AMO too,
> so RUSTC_SUPPORTS_RISCV depends on it as well.
> 
> The choice is made at compile time rather than with alternatives.
> Nearly every CPU has a native A extension, and an alternative would
> inflate all those kernels with the nops needed to pad one AMO to the
> size of an LR/SC loop, at every atomic site, for the benefit of a few.
> 
> Turning Zaamo off needs a compiler that accepts _zaamo and _zalrsc in
> -march. GCC 15.1 is the first release that does.
> TOOLCHAIN_HAS_ZALRSC_ZAAMO checks for it; with an older compiler the
> option stays at y.
> 
> Three sets of extensions provide every atomic Linux needs. "a" is what
> the kernel supports today. Zalrsc plus Ziccrse is what this patch adds:
> every atomic is a constrained LR/SC loop, and Ziccrse is the
> forward-progress guarantee for such loops. Zaamo plus Zacas would do
> as well, with CAS loops in place of LR/SC as on x86, and is left for
> whoever has such hardware.
> 
> Suggested-by: Chao-ying Fu <chao-ying.fu@globalfoundries.com>
> Nacked-by: Conor Dooley <conor.dooley@microchip.com>
> Link: https://lore.kernel.org/linux-riscv/20261106-smock-headband-d6a7d568c228@spud/

I had a quick glance at this revision, and I think you've at least tried
to resolve the things I was pointing out. Did I miss something, or why
have you kept the NAK after having resolved the things that I was
objecting to?

Thanks,
Conor.

> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]