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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <AS2PR09MB6296A1D1EF4ABD1C45202440948BA@AS2PR09MB6296.eurprd09.prod.outlook.com>
Date: Mon, 19 Jan 2026 07:29:16 +0000
From: Vladimir Kondratiev <Vladimir.Kondratiev@...ileye.com>
To: Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>
CC: Will Deacon <will@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
	Boqun Feng <boqun.feng@...il.com>, Mark Rutland <mark.rutland@....com>, Gary
 Guo <gary@...yguo.net>, Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti
	<alex@...ti.fr>, Yury Norov <yury.norov@...il.com>, Rasmus Villemoes
	<linux@...musvillemoes.dk>, Chao-ying Fu <cfu@...s.com>, Aleksandar Rikalo
	<arikalo@...il.com>, Aleksa Paunovic <aleksa.paunovic@...cgroup.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"olof@...om.net" <olof@...om.net>
Subject: Re: [PATCH] riscv: support CPUs having only "zalrsc" but no "zaamo"

> > 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.

> 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. 

> 
> Palmer might have some other thoughts here.

Thanks, Vladimir