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

From: "Gary Guo" <gary@garyguo.net>
To: "Vladimir Kondratiev" <Vladimir.Kondratiev@mobileye.com>,
	"Paul Walmsley" <pjw@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>
Cc: "Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Chao-ying Fu" <cfu@mips.com>,
	"Aleksandar Rikalo" <arikalo@gmail.com>,
	"Aleksa Paunovic" <aleksa.paunovic@htecgroup.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"olof@lixom.net" <olof@lixom.net>
Subject: Re: [PATCH] riscv: support CPUs having only "zalrsc" but no "zaamo"
Date: Mon, 19 Jan 2026 17:17:19 +0000	[thread overview]
Message-ID: <DFSQIY6WV4U7.3B3RY31KE739B@garyguo.net> (raw)
In-Reply-To: <AS2PR09MB6296A1D1EF4ABD1C45202440948BA@AS2PR09MB6296.eurprd09.prod.outlook.com>

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

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