Re: [PATCH v4] riscv: Use Zalrsc extension to implement atomic functions

Jesse Taube <[email protected]>
Newsgroups org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel
Message-ID <CADRr4bcd5Bm7bdB7RwE=XBBq7igH0H4x2Ok0MLTMEv8P0+S-8g@mail.gmail.com>
On Mon, Aug 10, 2026 at 12:46 PM Conor Dooley <[email protected]> wrote:
>
> On Thu, Jul 23, 2026 at 05:51:53PM +0200, Aleksa Paunovic wrote:
> > From: Chao-ying Fu <[email protected]>
> >
> > MIPS P8700 does not natively support Zaamo instructions.
> > They are emulated with Zalrsc extension instructions instead [1].
> > Since the emulation is implemented through M-mode traps in the SBI
> > layer, it is best to avoid using these instructions wherever possible on
> > the P8700.
> >
> > Implement kernel atomic operations using LR/SC sequences only.
>
> > This is achieved by using the errata mechanism, with minimal
> > interference on other cores.
>
> This does not seem appropriate, you don't have an actual erratum.
> Rather, you don't meet the minimum extension requirements that linux
> currently has and want to avoid emulation.
>
> >
> > Signed-off-by: Chao-ying Fu <[email protected]>
> > Signed-off-by: Aleksandar Rikalo <[email protected]>
> > Co-developed-by: Aleksa Paunovic <[email protected]>
> > Signed-off-by: Aleksa Paunovic <[email protected]>
> >
> > [1] https://mips.com/wp-content/uploads/2026/03/MIPS_P8700_P8700-F_Programmers_Reference_Guide_Rev1.86_2-17-2026.pdf
>
> This should be a Link: tag, and be above the signoffs.
> >
> > ---
> > The patch was tested on QEMU configured to emulate an eight-hart MIPS P8700 CPU.
> > Testing done since v3: futex kselftests and perf futex tests. These tests caught the issues described below.
> > The same tests were executed on the Boston board with a single-hart P8700 core.
> >
> > Since the main issue was with an incorrectly written erratum, it shouldn't affect Vladimir's version [1].
> > However, since chips supporting only one part of the A extension are rare, we believe it might be
> > better to address this using the alternative mechanism, instead of demanding that the wider community
> > relax the A extension requirement.
>
> Alternatives, sure. Relaxing the A extension requirement on the other
> hand basically makes no difference, if we have to insert an alternative into
> anything using AMO instructions, may as well do it properly and support Zalrsc
> only systems rather than abuse the errata mechanisms.

I think the issue would be riscv_cpufeature_patch_func doesn't get called
in RISCV_ALTERNATIVES_EARLY_BOOT. I also think that we should
do it properly and support Zalrsc only systems, but this is a step in
the right direction.
I've been personally interested in getting this to work for a while,
and want to continue my efforts
especially now that there are products backing it.

> Any multiplatform kernel
> (so anything provided by a distro) is going to turn on any errata that are not
> listed as being non-portable.
>
> The minimum requirements have been known for a long time too, since the
> port was merged, so I personally don't feel charitable here. Your
> firmware already can deal with the emulation, so I don't really see why
> we should be adding alternatives because people selling (or buying) IP
> cannot be bothered to meet the extremely basic minimum requirements of the
> software they want to support.

I would assume it's because emulation is very slow.

Thanks,
Jesse Taube

>
> >
> > Changes in v4:
> > - The amo part of the ALT_TEST_AND_OP_BIT_ORD erratum erroneously hardcoded zero as the destination register.
> >   This is fixed in v4.
> > - futex.h was missing the ANDN case.
> > - Link to v3: https://lore.kernel.org/r/[email protected]
> >
> > Changes in v3:
> > - Use alternatives to replace AMO instructions with LR/SC
> > - Rebase on Alexandre Ghiti's "for-next" branch.
> > - Link to v2: https://lore.kernel.org/linux-riscv/[email protected]/
> >
> > Links:
> > [1] https://lore.kernel.org/linux-riscv/[email protected]/
> >
> > Signed-off-by: Aleksa Paunovic <[email protected]>
> > ---
> >  arch/riscv/Kconfig.errata                    |  11 ++
> >  arch/riscv/errata/mips/errata.c              |  13 +-
> >  arch/riscv/include/asm/atomic.h              |  29 ++--
> >  arch/riscv/include/asm/bitops.h              |  28 ++--
> >  arch/riscv/include/asm/cmpxchg.h             |   9 +-
> >  arch/riscv/include/asm/errata_list.h         | 215 +++++++++++++++++++++++++++
> >  arch/riscv/include/asm/errata_list_vendors.h |   3 +-
> >  arch/riscv/include/asm/futex.h               |  40 ++---
> >  arch/riscv/kernel/entry.S                    |  10 +-
> >  9 files changed, 290 insertions(+), 68 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig.errata b/arch/riscv/Kconfig.errata
> > index 3c945d086c7d0266b685f9506d58b0662af071c4..cd5bd5e8eb395418c3ad103dbd836c775b7fd901 100644
> > --- a/arch/riscv/Kconfig.errata
> > +++ b/arch/riscv/Kconfig.errata
> > @@ -44,6 +44,17 @@ config ERRATA_MIPS_P8700_PAUSE_OPCODE
> >
> >          If you are not using the P8700 processor, say n.
> >
> > +config ERRATA_MIPS_P8700_AMO_ZALRSC
> > +     bool "Replace AMO instructions with LR/SC on MIPS P8700"
> > +     depends on ERRATA_MIPS && 64BIT
> > +     default n
>
> Why is this default n if your platform does not work without it?
>
> Cheers,
> Conor.
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.