[PATCH v4] riscv: Use Zalrsc extension to implement atomic functions
Jesse Taube
jtaubepe at redhat.com
Tue Aug 18 11:39:45 PDT 2026
On Mon, Aug 10, 2026 at 12:46 PM Conor Dooley <conor at kernel.org> wrote:
>
> On Thu, Jul 23, 2026 at 05:51:53PM +0200, Aleksa Paunovic wrote:
> > From: Chao-ying Fu <cfu at mips.com>
> >
> > 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 <cfu at mips.com>
> > Signed-off-by: Aleksandar Rikalo <arikalo at gmail.com>
> > Co-developed-by: Aleksa Paunovic <aleksa.paunovic at htecgroup.com>
> > Signed-off-by: Aleksa Paunovic <aleksa.paunovic at htecgroup.com>
> >
> > [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/20250901-p8700-zalrsc-v3-1-ec64fabbe093@htecgroup.com
> >
> > 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/20241225082412.36727-1-arikalo@gmail.com/
> >
> > Links:
> > [1] https://lore.kernel.org/linux-riscv/20260120-lrsc-only-v2-0-a522e640d27d@mobileye.com/
> >
> > Signed-off-by: Aleksa Paunovic <aleksa.paunovic at htecgroup.com>
> > ---
> > 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
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
More information about the linux-riscv
mailing list