RISC-V Support?

@luhenry

Current status maintained in this comment by @luhenry

Previously:

Your question:

I'd like to start a discussion about adding limited support for RISC-V architectures. I'm in the process of helping some colleagues at UC Berkeley transition to using conda-forge instead of system packages for https://fires.im/ and https://chipyard.readthedocs.io/en/stable/. We've transitioned the system yum and pip packages to using conda-forge. The next steps are:

to create packages for other x86 things we currently build from source (e.g. libdwarf and QEMU)
migrate pre-compiled toolchain install https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/Initial-Repo-Setup.html#building-a-toolchain (--ec2-fast) to using conda instead of the current tarball extraction technique that is limited in it's portability and has no infrastructure to help in it's maintenance.

Adding the toolchain makes me wonder -- does it make sense to start adding RISC-V architectures to conda-forge? For starters, centos does not support it yet (Fedora does). The current use model builds and installs https://github.com/riscv-collab/riscv-gnu-toolchain into a $RISCV prefix (many scripts use the RISCV environment variable) and then installs more RISC-V ABI software into that same prefix. I assume that conda-forge would want the cross-toolchain to be installed into a linux-64 "build prefix" and the subsequent software installed into a prefix that is architecture-specific (for the sake of simplicity, I'm only considering linux-rv64gc for now because there are many pieces and options when it comes to RISC-V isa). Come to think of it, we may just want to call it linux-rv64 and not have more details of which ISA pieces are actually supported encoded in the platform name.

Regardless of whether @conda-forge/core is interested in adding RISC-V platforms, to be able to upload to a new platform type on anaconda.org, we would need to get support for it from Anaconda, right? How does that work when conda-forge supports a platform that upstream Anaconda doesn't? (e.g. linux-aarch64)

Just went through the exercise of listing all the packages we need to exist on conda.anaconda.org/conda-forge/ to get a working linux-anvil-riscv64 docker image (as of April 8th, 2026).

I broke it down into 4 layers:

Layer 0: what's needed to get cross-compilation going (listed above)
Layer 1: what's needed to get the micromamba-feedstock built
Layer 2: dependencies of Miniforg3 as listed in miniforge/Miniforge3/construct.yaml
Layer 3: packages installed in the linux-anvil-riscv64 docker image as listed in docker-images/scripts/run_commands

Layer 0: toolchains

Built on linux-64, targeting riscv64. The binaries run on x86_64 or riscv64 but produce output for riscv64.

	Package	Subdir	F…

These two issues will probably help you get an idea of what's needed (especially #1123 (comment)):

...able to upload to a new platform type on anaconda.org...

Just checked; anaconda.org already supports uploading of linux-riscv64 conda packages.

@bitsk

Following the initial outreach on zulip, the OpenKylin community presented their case for building up riscv64 in conda-forge in the most recent core call (minutes). While there are several open questions, the way I interpreted the overall impression of the call is that @conda-forge/core is generally interested and willing to find ways together to make this work.

Some open topics:

Native hardware support:
- apparently substantial resources can be provided for native CI. One possibility that was mentioned was plugging this into self-hosted github action runners. Not sure if this is in scope of cirun or would be done separately.
ABI varieties of riscv64:
- Apparently this is mostly rv64gc and the newer RVA23; the latter is a superset of the former, so these are not divergent ABIs per se, just regular evolution/extension. Quoting from that Zulip thread: "The best example is Ubuntu: 24.04 was rv64gc, but 25.10 will be RVA23-only." I trust the OpenKylin team to make a recommendation here, but since we're starting from scratch, I think we can go with the newer instruction set that everyone is apparently moving to anyway.
[something else I forgot?]

Some of these questions will have longer lead times (e.g. CI integration), but we don't need to solve everything at once. On a shorter time horizon, the first step is to bootstrap the necessary compilers. Copying the checklist from here:

Ask for volunteers for conda-forge/help-riscv64 team to support riscv64. (At least two people who'll respond to github issues quickly)
- OpenKylin community mentioned being able to have 2-3 people on this full time; these are: Tianxiang Bian @bitsk, Jiankang Li @lijkang, Ruian Zhan @scorbunny-cinderace
- Create @conda-forge/help-riscv64 team governance#18
Ask Anaconda, Inc to support uploading riscv64 packages to anaconda.org.
- already done, as mentioned by Cheng above
Add riscv sysroot; switch to rockylinux linux-sysroot-feedstock#93
- after Add alma10 sysroot linux-sysroot-feedstock#92 for first glibc 2.39 support
- c.f. roll-out of glibc 2.39 / RHEL10-derived infrastructure #2657 -- almalinux does not currently provide packages for riscv, but rockylinux does.
- Update build-sysroot.sh to create symlinks for RISC-V ABI libraries linux-sysroot-feedstock#98
Add support for RISC-V architecture binutils-feedstock#106
Build a cross compiler for riscv64 in https://github.com/conda-forge/ctng-compilers-feedstock
- Add support for RISC-V architecture ctng-compilers-feedstock#205
Build a cross-native compiler for riscv64 in https://github.com/conda-forge/ctng-compilers-feedstock

@h-vetinari

Hi,@h-vetinari! Here are our openKylin participants: Tianxiang Bian @bitsk , Jiankang Li @lijkang, Ruian Zhan @scorbunny-cinderace

We need to update the QEMU version in docker-images to 10 to support RVA23(SE_01_021 - QEMU RVA23 profile support).

However, the QEMU 10 packages in the Fedora repository (e.g., 10.1.2)are built for fc43 and fc44 and may not run on alma or rocky.

However, the QEMU 10 packages in the Fedora repository (e.g., 10.1.2) are built for fc43 and fc44 and may not run on alma or rocky.

You might be interested in conda-forge/docker-images#320 ;-)

Great, understood. We need to add emulated_targets to QEMU. I also noticed that the tests depend on sysroot_linux-riscv64, so we might need to wait for the sysroot build to complete.

it's work

@bitsk

conda-forge/linux-sysroot-feedstock#93 has been merged. @bitsk, @lijkang, @scorbunny-cinderace, are you planning to tackle binutils and the compilers? I'm not really planning to do that myself. Help on the qemu side is also welcome, though there at least it's on my list of planned things, because it'll be useful in any case.

We will begin the subsequent merging process. conda-forge/binutils-feedstock#106

planning to tackle binutils and the compilers

conda-forge/binutils-feedstock#106 is merged 🥳

next up: fighting with the main GCC feedstock 🙃

The GCC PR is available here: conda-forge/ctng-compilers-feedstock#205

@h-vetinari

Hi @h-vetinari @isuruf, just a quick update on our recent progress.

We expect to receive our first batch of RVA23 development boards (8+8 cores) in about two weeks. We’ve just had a chance to test them, and the performance has exceeded our expectations. Additionally, we’ve made significant progress with our RISC-V porting on OpenStack, which is now running successfully on the UltraRISC RISC-V platform.

I would also like to introduce Chenguang Ding (@Divinity96) and Zhuoheng Li (@zohanzephyr) from KylinSoft, who will be joining our subsequent efforts. They will be focusing on patches for base software and fixing build issues.

The RVA23 boards have arrived.

It works!

(base) root@256803bf8131:/# conda install python
Retrieving notices: done
Channels:
 - conda-forge
Platform: linux-riscv64
Collecting package metadata (repodata.json): done
Solving environment: done

# All requested packages already installed.

That's after installing Miniforge from https://github.com/conda-forge/miniforge/releases/tag/26.7.2-0. Congrats everyone! 🎉

As we are getting closer to have native builds on RISC-V, I took a quick look at what packages are the most downloaded from conda-forge. Using condastats, I got that information for the month of 2026-08: https://gist.github.com/luhenry/341794d80a9e325fc3a96d243f7e25e3.

Once we have the native runners, we can go through that list by adding them in batch to linux_riscv64.txt

We now have the linux-anvil-riscv64 docker image available 🎉

@luhenry

How large is the fleet of runners from RISE? @luhenry

We haven't even switched to native builds yet, but already I'm seeing long waits (>10min and climbing) for runners to be provisioned - there can't be more than a handful of feedstocks being tested on these machines yet (I'm aware of 3 that have unmerged PRs, and only one of those has CI running right now), so this would be a pretty major bottleneck.

How large is the fleet of runners from RISE? @luhenry

We haven't even switched to native builds yet, but already I'm seeing long waits (>10min and climbing) for runners to be provisioned - there can't be more than a handful of feedstocks being tested on these machines yet (I'm aware of 3 that have unmerged PRs, and only one of those has CI running right now), so this would be a pretty major bottleneck.

There are 55 machines right now. I've pushed quite a few changes in https://github.com/riseproject-dev which has led to higher peak than usual. I'll reduce the max usage of riseproject-dev so that there is more breathing room for other orgs.

Increased limit for conda-forge: riseproject-dev/riscv-runner@7394c8b

@velonica0

FWIW, conda-forge/coreutils-feedstock#37 was built fully natively, so that's a good sign. However, I want to flag the following difference in runtimes across architectures (ppc is cross-compiled, so not apples-to-apples, but irrelevant for the overall job runtime)

That kind of differential between runners architectures will make it quite painful to progress on broader migrations (e.g. for new python versions), to say nothing about the average turn-around for iterating on changes of a feedstock. The same result occurred when merging to main, so it was not a one-off fluke either.

@velonica0 mentioned in conda-forge/conda-smithy#2698 that

We have OpenKylin machines with UltraRISC DP1000 boards that we'd like to connect through the RISE app, so the ubuntu-24.04-riscv label stays the same.

Do we have an idea where those machines land in terms of compute power w.r.t. to the current RISE runners? Also, how many OpenKylin machines are we talking about (vis-à-vis the 55 from RISE), and will the be a possibility to influence the runner choice, or will it just be one large pool? Having very divergent runner profiles in the same pool can be quite annoying, because CI jobs that passed fine a big runner might start failing if they randomly hit a slower one.

@velonica0

Do we have an idea where those machines land in terms of compute power w.r.t. to the current RISE runners?

I would expect at least a 3-4x speedup.

Also, how many OpenKylin machines are we talking about (vis-à-vis the 55 from RISE)

I will let @velonica0 answer here.

will the be a possibility to influence the runner choice, or will it just be one large pool?

We 100% have influence on runner choice. We can limit ourselves exclusively to the openKylin machines if there are enough. I wouldn't want to have 1 big pool where machines are chosen randomly since there is quite a big difference in terms of performance. We can have a tag to decide which one to have.

Two DP-1000 units to start with, 8 cores and 16 GB RAM each, and we expect to add more later.

On the speedup, a measured number rather than an estimate: building coreutils-feedstock natively with the same recipe, the same image and CPU_COUNT=4 to match the RISE runner's parallelism, the DP-1000 took 603 s against 1826 s on an EM-RV1, so 3x at identical parallelism.

The remaining blockers on our side are network access and permissions rather than anything with the machines themselves. We're working through those and will hand the units over to RISE once they're sorted.

@luhenry

Thanks a lot for the details @luhenry @velonica0! 🙏

Even assuming a very optimistic quadrupling of the current 2 DP-1000 units (and successful integration through RISE), a situation of

55 EM-RV1 with ~9x slowdown compared to other arches
8 DP-1000 with ~3x slowdown compared to other arches

sounds to me like: we should have separate pools for these runners, and more importantly: that native compilation for riscv should be opt-in rather than the default, for feedstocks that require it, or would like to benefit from better testing. Otherwise we're just creating very tight bottlenecks all over conda-forge -- either by drastically longer runtimes or by congestion for the few available faster runners.

Just as a back-of-the-envelope guesstimate, I'd say that we'd need to have at least ~40-50 fast machines (DP-1000 or better) in a pool before going native by default becomes feasible.

CC @conda-forge/core

As far as I know, the DP-1000 is currently the highest-performance hardware based on the RVA22 profile, and upcoming SoCs from major RISC-V hardware vendors will all adopt RVA23

Will the Conda community be open to supporting the latest RVA23 profile? After all, RVA23 includes the vector extension by default.

If RVA23 makes a meaningful impact on the runtimes of builds, then I think it definitely should be discussed as an option. The overall calculus remains pretty much the same though: for native-by-default, we need 50+¹ runners of roughly comparable performance to what the other platforms take to run (and a slowdown by a factor of 3 is stretching "roughly comparable" to its limit IMO).

or whatever number is necessary to not constantly have congestion across regular feedstock operations (assuming all widely-used feedstocks will end up supporting riscv), much less large-scale migrations. ↩

@velonica0

👋 Giving a quick update as it's already been a week.

@velonica0 shared access to 2 runners with 8 cores / 16Gb RAM each. I did set them up to connect to RISE Runners kubernetes cluster, but I ran into some issues with the kernel available in these VMs (see small write-up). I'm waiting to hear back on that.

On the existing runners, I heard back from Scaleway and they should be adding some machines back to the pool, so I'll increase the number of machines RISE has access to ~85. That will give us some breathing room and make sure we have more than enough hardware to scale up when needed. I'm still working on getting faster hardware hosted by RISE, but the global supply chain issues with RAM are making things more difficult... I'll keep everyone updated on this issue.

@luhenry

Hi,@luhenry

The openkylin team is on vacation and can't use computers for now.

We'll be back in the office in about a week and will handle things as soon as possible then.

Thanks for your help!

@bitsk

Hello, quick update on that. I got to meet with @bitsk, @velonica0 and others from openKylin in person at the RVI Summit China this week. The openKylin hardware is available through the RISE RISC-V Runners with the [ubuntu-24.04-riscv, ur] 1 tags to validate it works as expected, and I'll change the tag to ubuntu-24.04-riscv only. We are still working to enable RVA23 hardware and in sufficient volume that we can support the broader linux-riscv64 migration.

@bitsk, @velonica0, could you please give a spin to a feedstock with the [ubuntu-24.04-riscv, ur] labels for the runner to validate everything works.

Thanks!
See conda-forge/llvmdev-feedstock#395

Navigation Menu

Repository navigation

RISC-V Support? #1744

Your question:

Layer 0: toolchains

55 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

RISC-V Support? #1744

Description

Your question:

Layer 0: toolchains

Activity

chrisburr commented on Apr 27, 2022

chenghlee commented on Nov 12, 2025

h-vetinari commented on Nov 15, 2025

bitsk commented on Nov 18, 2025

bitsk commented on Nov 18, 2025

h-vetinari commented on Nov 18, 2025

bitsk commented on Nov 19, 2025

bitsk commented on Nov 19, 2025

h-vetinari commented on Dec 19, 2025

bitsk commented on Dec 19, 2025

h-vetinari commented on Dec 25, 2025

bitsk commented on Dec 25, 2025

bitsk commented on Jan 8, 2026

bitsk commented on Jan 19, 2026

55 remaining items

luhenry commented on Sep 9, 2026

luhenry commented on Sep 11, 2026

luhenry commented on Sep 14, 2026

h-vetinari commented on Sep 22, 2026

luhenry commented on Sep 22, 2026

h-vetinari commented on Sep 23, 2026

luhenry commented on Sep 23, 2026

velonica0 commented on Sep 24, 2026

h-vetinari commented on Sep 24, 2026

velonica0 commented on Sep 24, 2026

h-vetinari commented on Sep 24, 2026

Footnotes

luhenry commented on Oct 1, 2026

velonica0 commented on Oct 2, 2026

luhenry commented on Oct 24, 2026

velonica0 commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions