[PATCH v2 0/2] Support for Risc-V CPUs implementing LR/SC but not AMO

[Aleksa Paunovic]

Hi Paul,

On 1/21/26 19:19, Paul Walmsley wrote:
> Hi Vladimir,
>
> On Tue, 20 Jan 2026, Vladimir Kondratiev wrote:
>
>> Primary goal is to support Mobileye eyeq7h automotive platform
>> based on MIPS P8700 CPU [1] having only "zalrsc" ISA extension but
>> not full "a".
>>
>> Such platforms need userspace to be compiled with correct
>> "-march" flags to generate proper instructions for the atomic types
>> so there's not feasible to use universal userspace for it.
>> Thus there's no point to do same binary kernel suitable for both
>> "full A" and "LRSC only" platform types. Do a compile time
>> alternatives and require CONFIG_NONPORTABLE for this
>>
>> [1] https://mips.com/products/hardware/p8700/
>>
>> Patch 1 do most of work to provide compile-time LR/SC alternatives
>>         for the AMO instructions
>> Patch 2 adjust tests for reported CPU extensions compatibility with
>>         the code
>>
>> Changes in v2: switch from dynamic atomic flavor resolution to
>> compile-time one.
>>
>> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev at mobileye.com>
> Thanks for updating the patches so quickly to deal with Gary's comments. I
> think we should hold off on merging them until common userspace providers
> (like Linux distributions) or distribution builders (like OE/Yocto or
> Buildroot) merge support for this configuration, along with underlying
> projects like glibc.  That way, the rest of us have a way to test our
> patches on this unusual configuration before sending them to the list, or
> sending PRs upstream.  It should be straightforward to get the Zalrsc-only
> userspace support patches tested on existing RISC-V Linux hardware, since
> it supports a superset of this behavior.  I guess the only question is
> whether other projects are interested in committing to carrying forward
> the necessary changes.

Zaamo instructions are emulated on the SBI level, so testing any future patches
on this configuration shouldn't be an issue. We have been using userspaces
with libraries compiled with upstream GCC releases for a while now.  

Of course, a Zalrsc-only userspace would probably work faster on the P8700.

> It also would be good to see publicly available MIPS P8700 boards being
> used on an ongoing basis by at least one active participant on this list,
> who can post Tested-by:s for key series and who can post review feedback
> and Reviewed-by:s for other RISC-V patch series.  That way, we'd have more
> confidence that there actually is an ongoing user population for this
> board who cares about upstream.  This is particularly important for folks
> who care about these MIPS P8700 cores, which don't seem to be a
> from-scratch design for RISC-V, and which don't have AMO support like all
> of the other cores we support.  (For what it's worth, we're trying to
> foster this engagement for other core microarchitectures as well; thanks
> Joel Stanley of TensTorrent, Andrew Jones and Anup Patel of
> Ventana/Qualcomm, and Andreas Korb of Fraunhofer working on the Core-V
> designs for showing how this is done.)

We tested the series on an eight-core QEMU configuration and the Boston board with a single-core MIPS P8700 CPU. 
Most of the testing was done using kselftests (futex, rseq, ptrace, and locking). 
We also ran an overnight locktorture test on the board, which completed without any issues. I should
note that the kernel we used for locktorture testing on the board was non-preemptive. I also ran a
brief rcutorture test on QEMU (a few hours) which showed no issues. 

The kernel was compiled with GCC 15.1.0, using GNU Binutils version 2.45. 

Best regards,
Aleksa Paunovic