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

[Gary Guo]

On Mon Jan 19, 2026 at 7:29 AM GMT, Vladimir Kondratiev wrote:
>> > 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?
>
> I don't know, I am working with the Mobileye platform only
>
>> Are development boards available yet for these kinds of designs?
>
> Sorry, no. Mobileye does not release (as of now) boards to the public, it
> works only with automotive companies
>
> <skip> 
>> > 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?
>
> Absolutely agree; this is why I re-factored this as a generic feature
> rather than errata.
>
> <skip>
>> 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? 
>
> Yes indeed. In fact, any AMO instruction may be re-implemented as an LR/SC
> sequence provided memory area is LR/SC capable; opposite is not true.
> Actually "a" is not a real requirement to implement atomics, we just need
> some way to do so, and "LR/SC only" is sufficient.

Most RVA processors today the full A extensions, and multiple distros built
software for the full A extensions. On these machines you're just adding
extra space overhead to all atomic accesses.

At minimum, it needs to be something that can compiled out completely using
Kconfig, so say, Debian's RISC-V build won't need to include any of these. The
need to rebuild entire userspace certainly suggest that ALTERNATIVE mechanism
isn't the correct tool here.

>
>> 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.
>
> Userspace should provide "-march=rv64imc_zalrsc" instead of "-march=rv64imac"
> for all compilation; this will instruct compiler to use LR/SC for atomic_t and alike
>
> <skip>
>> 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?
>
> I understand the argument, but I can't say for all risc-v community or how
> important is Mobileye chip to justify special support.
> CPU vendor is MIPS, perhaps they can share arguments about decision to
> implement only LR/SC but not AMO.
> Good if people crafting LR/SC only platforms will comment here. 

I'd be curious to know if any kind of performance evaluation has been done.
atomic_inc is quite heavily used in the kernel.

Best,
Gary

>
>> 
>> Palmer might have some other thoughts here.
>
> Thanks, Vladimir