Re: [PATCH] riscv: support CPUs having only "zalrsc" but no "zaamo"

[Paul Walmsley <pjw@kernel.org>]

Hi,

On Wed, 14 Jan 2026, Vladimir Kondratiev wrote:

> riscv have 3 instruction set extensions related to atomic operations:
> - "zaamo": atomic instructions like AMOADD
> - "zalrsc": LR and SC instructions
> - "a" that is "zaamo" + "zalrsc"
> 
> Historically, "a" was first, and Linux was relying on "a";
> then "zaamo"/"zalrsc" was introduced. It is possible to implement
> most atomic operations with either AMO or LR/SC. AMO if more efficient
> however more complex flows are possible with LR/SC only.
> 
> Platforms supporting only part of atomics starting to appear.
> Notable is MIPS P8700 CPU [1] having only "zalrsc".

Are there any others?

Are development boards available yet for these kinds of designs?

> CPU reports ISA extensions supported in the "riscv,isa-extensions"
> property of the CPU OF node. Platform supporting "zalrsc" only should
> report "zalrsc" but no "a" in this property.
> 
> For the early stages of execution, before alternatives applied,
> (ex: head.S) CPUs having no "zaamo" extension rely on firmware
> emulating AMO through "invalid instruction" trap to the M-mode.
> 
> Speed-up the rest of execution using ALTERNATIVE,
> replacing AMO versions with LR/SC ones
> 
> Implementation is generic, inspired by the patch [2]
> by developers listed below, implementing similar patch as errata
> for the MIPS P8700 CPU

This doesn't look like an erratum.  The designers of this core just chose 
not to implement A support in this CPU, and that's why that AMO_II bit 
exists in the mipsconfig6 register, correct?

> [1] https://mips.com/products/hardware/p8700/
> [2] https://lore.kernel.org/all/20251014-p8700-zalrsc-v3-1-9d81bd8093e0@htecgroup.com/
> 
> Suggested-by: Chao-ying Fu <cfu@mips.com>
> Suggested-by: Aleksandar Rikalo <arikalo@gmail.com>
> Suggested-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

I guess the proposal here is for the upstream kernel community to weaken 
our A support requirement to support these special cores that only support 
LR/SC?  

If so, I suppose the question is, should anyone in the upstream kernel 
community care about this case?  It wouldn't be enough for the kernel 
alone to support this.  A special userspace would also be needed.

This looks like a variant of the big-endian issue discussed earlier, 
 
  https://lore.kernel.org/linux-riscv/CAHk-=wgfpswvq0TypePyjv3dofO5YaUC_fSd_MjzY7jogCUnCg@mail.gmail.com/

If we take these changes, it increases the complexity of the upstream 
kernel, and increases our testing matrix as maintainers (and, in theory, 
for any patch submitters, who should theoretically be testing their work 
on the configurations that we support).  It's not clear what the gain 
would be for the broader community.  As maintainers, we're already 
considering stripping out other code that doesn't seem to have significant 
community support, like no-MMU, for similar reasons.

On the other hand, if boards with Zalrsc-only cores seemed popular in the 
marketplace, and some sort of support existed in common userspaces, such 
that we could be sure that there was some sort of commitment to maintain 
this across the entire ecosystem, the discussion could be more favorable, 
I guess?

Palmer might have some other thoughts here.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv