[lustre-devel] [RFC] RISC-V Architecture Support for Lustre - Patch Series Available

[Andreas Dilger]

On Feb 24, 2026, at 04:09, Abdul Halim <abdul.halim at openchip.com> wrote:
> 
> Hello Lustre developers and maintainers,
> 
> I am writing to inquire about any existing plans to support the RISC-V
> architecture in future Lustre releases, and to share our work on enabling
> Lustre client functionality on RISC-V 64-bit systems.

[snip many good reasons for supporting RISC-V]

I don't think there needs much "convincing" for Lustre to add support
for RISC-V.  The main obstacle for doing this successfully is that
Lustre developers do not have access to RISC-V hardware for testing.

Advancing RISC-V from "it works *right now*" over to "it is supported"
needs someone to host hardware that can build new patches/releases under
development and run testing on an ongoing basis. That avoids regressions,
provides much needed coverage to find occasional failures caused by race
conditions, and ensures these systems continue to work going forward. 


Realistically, having 6-8 RISC-V machines running VMs should have enough
capability to keep up with patches under development to at least build
and run basic client testing - runtests, sanity, sanity-lnet, and maybe
more as time permits (patch production is definitely not uniform).  Each
host could run several VMs (4 cores, 4 GiB RAM, some NVMe for the builds),
doing a build and testing it as much as it can.

Unless you have a fundamental objection to doing so, it probably makes
sense to start with x86_64 server VMs (4 cores, 4 GiB RAM, 1TB NVMe or
16GiB ramdisk MDS+OSTs) just to isolate runtime issues to RISC-V clients
until they are robust, and then add RISC-V servers afterward (once manual
test/fix is finished, and pending additional test hardware).

I'm not very familiar with RISC-V, so some important questions:
- does it normally use large PAGE_SIZE (e.g. 64 KiB)?  Large pages mostly
  work (also used on aarch64), but occasionally needs fixes.
- does it use little-endian (preferred) or big-endian?  We haven't had any
  "primary" big-endian architectures for ages, so it needs work to fix.
- does it have strong or weak memory ordering?  There is likely code that
  depend on x86 memory ordering semantics and will need to be fixed over
  time.  ARM has weaker memory ordering semantics and fixes are sometimes
  needed.  Lustre has been around a long time and race condition testing
  is pretty robust, so I don't think this will be a huge issue.

> OUR WORK: LUSTRE 2.17.0 ON RISC-V
> ---------------------------------
> 
> We have successfully built and tested the Lustre 2.17.0 client on RISC-V
> 64-bit with a minimal set of patches. This work demonstrates that Lustre
> can be ported to RISC-V with relatively low effort, as also shown in
> recent academic work by Billa et al. at SCA/HPCAsiaWS '26 [2].
> 
> Patch Summary:
> 
> Our patch series consists of 8 small patches targeting:
> 
>   - Build system:      RISC-V SUBARCH mapping in autoconf
>   - RPM/DKMS:          Architecture-agnostic paths
>   - LNet:              RISC-V hypervisor detection handling
>   - llite:             Guard for prefetchw() (x86-specific instruction)
>   - Erasure coding:    Enable optimized paths for RISC-V
>   - Debug tools:       RISC-V target in crash tools
> 
> Total impact: 9 files changed, 19 insertions(+), 8 deletions(-)

Great.  There shouldn't be any issue accepting such trivial patches, even
before the testing systems can be brought online.

> Test Environment:
> 
>   - Primary:    Ubuntu 24.04 RISC-V, Linux kernel 6.8.4
>   - Validation: Fedora 42 x86_64, Linux kernel 6.16.4
>   - Result:     All 16 client kernel modules compile and load successfully

Beyond loading the kernel modules, have you run any testing on the code?
Running runtests, sanity, and sanity-lnet would be the minimum to show
that this code is functional beyond just "it compiles, ship it" ;-).

> QUESTIONS FOR THE COMMUNITY
> ---------------------------
> 
>   1. Are there any existing plans or ongoing efforts to add RISC-V
>      support to Lustre?

Lustre is an open development community.  These things happen when someone
makes them happen... IIRC there was an email to lustre-discuss a few months
ago, but nothing came of it AFAIK.  You are the one with the most interest
to get this working and keep it working, so it falls on you to do the work.

>   2. Would the maintainers be interested in reviewing our patch series
>      for potential inclusion?

Definitely yes.  The best way to make progress is to submit the patches.

>   3. Are there specific testing requirements or coding standards we
>      should address before formal submission?

There will be a lot of automated testing on the patches, but it will all
be done on x86_64 and aarch64 systems, so that will only ensure the patches
do not *break* those architectures, they won't show that RISC-V is *working*.

> NEXT STEPS
> ----------
> 
> We are prepared to:
> 
>   - Submit the patches via Gerrit for formal review
>   - Create a Jira ticket to track this feature request
>   - Provide additional testing data as needed
>   - Collaborate with maintainers on any required changes
> 
> The patches are available in our repository and we can submit them in
> whatever format is most convenient for the review process.

Great.  There are resources for contributors, but feedback on the content
and process is also welcome, since it is sometimes neglected:

https://wiki.lustre.org/Development - overview
https://wiki.lustre.org/Submitting_Changes - submission process overview
https://wiki.lustre.org/Using_Gerrit - details on pushing patches
https://wiki.lustre.org/Commit_Comments - details on commit message format


> REFERENCES
> ----------
> 
> [1] Nick Brown, "RISC-V HPC Gap Analysis", RISC-V International, Oct 2025
>     https://riscv.atlassian.net/wiki/spaces/OLRR/pages/895778831/HPC+Gap+analysis
> 
> [2] Surendra Billa et al., "Porting Lustre File System to RISC-V
>     Architecture", SCA/HPCAsiaWS '26, ACM
>     https://dl.acm.org/doi/10.1145/3784828.3785406
> 
> 
> Thank you for your time and consideration. We look forward to your
> feedback and the opportunity to contribute to Lustre's architecture
> support.
> 
> Best regards,
> 
> Abdul Halim
> OpenChip
> abdul.halim at openchip.com