Skip to content
Published on

The RISC-V RVA23 Profile — Distros Raised the Baseline, the Hardware Has Not Arrived Yet

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

Introduction — The Gap Between a Ratified Profile and the Hardware to Run It

RISC-V stories tend to come in one of two tones. Either "the open ISA is going to change the world," or "it's still a toy." Neither is much use. What a practitioner actually wants to know is one thing — if I target this today, what works and what doesn't.

This post tries to answer that question by betting it all on one profile: RVA23. RVA23 was ratified on October 21, 2024 (RISC-V International's announcement; the document itself reads Version 1.0, 2024-10-17: This document is in Ratified state.), and 21 months have passed since. In that time, Ubuntu raised this profile to a minimum requirement and built one LTS release on top of it. The profile has effectively been promoted from a spec to a product requirement.

But open Canonical's RISC-V download page today (July 16, 2026), and the only platform that can get a 26.04 LTS image is the QEMU emulator, one platform. All eleven of the remaining physical boards can only get 24.04.4 LTS. That gap is this post's subject.

Why Profiles Are a RISC-V-Only Thing

When you write x86 or Arm code, you don't worry about whether "this CPU has a multiply instruction." On RISC-V, you have to. Modularity was a design goal — extensions are picked à la carte, and vendors can even bolt on their own custom extensions.

In embedded, that's a strength — you compile all your own software. The problem is the market where you distribute binaries to other people. The ratification document's preamble is fairly candid about this tension.

The primary goal of the RVA profiles is to align processor vendors targeting binary software markets, so software can rely on the existence of a certain set of ISA features in a particular generation of RISC-V implementations.

The same document is blunter in the next paragraph. Without proactive alignment through profiles, RISC-V will be uncompetitive (Without proactive alignment through RVA profiles, RISC-V will be uncompetitive), and the reasoning goes: if one vendor implements a feature but another doesn't, binary distros won't use that feature, and everyone loses in the end.

That's the crux. A profile isn't a hardware feature — it's an agreement among hardware vendors. The software ecosystem picks the lowest common denominator it actually observes; it doesn't pick a feature because the spec table looks nice.

So the document states it flatly — to keep alignment and stay competitive, the mandatory extension set must increase over time in successive generations of the RVA profile (the mandatory set of extensions must increase over time in successive generations of RVA profile). That one sentence is RVA23's entire reason for existing.

What RVA23 Actually Mandates — V and H

The profile splits into two branches. RVA23U64 specifies what's visible in user mode; RVA23S64 specifies supervisor-mode features (i.e., what the kernel expects). As we'll see later, the one Ubuntu requires is S64.

Carried over verbatim from the ratification document, here's the list of new mandatory extensions in RVA23U64.

The following mandatory extensions are new in RVA23U64:
  V           Vector extension.          <- "V was optional in RVA22U64."
  Zvfhmin     Vector minimal half-precision floating-point.
  Zvbb        Vector basic bit-manipulation instructions.
  Zvkt        Vector data-independent execution latency.
  Zihintntl   Non-temporal locality hints.
  Zicond      Integer conditional operations.
  Zimop       may-be-operations.
  Zcmop       Compressed may-be-operations.
  Zcb         Additional compressed instructions.
  Zfa         Additional floating-Point instructions.
  Zawrs       Wait-on-reservation-set instructions.
  Supm        Pointer masking (PMLEN=0 and PMLEN=7 at minimum).

The line that really carries the weight is the first one. The ratification document's own annotation is V was optional in RVA22U64. And this is verifiable — the RVA22 profile text itself says RVA22U64 has four profile options (Zfh, V, Zkn, Zks). Vector was optional.

One detail that often gets blurred here: V also pins down the vector length. The vector extension spec states The V vector extension depends upon the Zvl128b and Zve64d extensions., and Zvl128b means VLEN is at least 128 bits. So for a chip that satisfies RVA23, a compiler doesn't just get to assume "there's a vector unit" — it can assume "there's at least a 128-bit vector register file and 64-bit floating-point vector ops work," with no runtime dispatch needed.

On the supervisor side (RVA23S64), the most expensive new mandatory item is Sha. The document calls it the augmented hypervisor extension, and in substance it bundles the H extension (hypervisor) with Ssstateen, Shcounterenw, Shvstvala, Shtvala, and more. And H, too, was optional under RVA22S64 — in the RVA22 text, H sits inside the RVA22S64 Optional Extensions section.

To sum up, RVA23's headline is this: Vector and Hypervisor, both optional under RVA22, are now both mandatory. That's a demand that genuinely grows silicon area and verification cost. It isn't free alignment.

A few lesser-known decisions are worth noting alongside this.

  • Scalar crypto dropped out. Zkn/Zks, optional under RVA22, aren't in RVA23's option list at all. The document's reasoning is clear — now that Vector is mandatory and vector crypto is far faster than scalar, the message to both is: move to vector crypto.
  • Control-flow integrity is still optional. Zicfilp (landing pads) and Zicfiss (shadow stack) are an expansion option in RVA23U64 — i.e., optional. Don't expect the equivalent of Arm's BTI/PAC defenses just because a chip says RVA23.
  • Zacas (compare-and-swap) is a development option. That means it's optional now and slated to become mandatory in the next generation. You can't assume an RVA23 chip has CAS.

Software Ran Ahead — Ubuntu's RVA23S64 Baseline

This is where the story gets interesting. Usually hardware ships first and software follows. Ubuntu went the other way.

The notice on Canonical's RISC-V download page states it precisely.

Note: We have upgraded the required RISC-V ISA profile to RVA23S64 with the 25.10 release. Hardware that is not RVA23-ready continues to be supported by our 24.04.4 LTS release.

The notable point is that what's required is not U64 but RVA23S64. As we saw above, S64 mandatorily includes Sha, i.e., the hypervisor. You don't actually need the hypervisor extension to run a desktop image, but if you adopt the whole profile as your baseline, it comes along regardless.

Canonical laid out the logic behind this decision in a February 2026 retrospective — to avoid ecosystem fragmentation and to keep pace with hardware partners. The same post also gives its answer to users being left behind.

Starting with Ubuntu 25.10, RVA23 became the minimum supported baseline. RVA20 users can still get up to 15 years of support, provided they are using Ubuntu 24.04 LTS with Ubuntu Pro.

That sentence deserves a fair reading. This isn't "abandoned." 24.04 LTS goes out to 15 years with Ubuntu Pro. Canonical even states it added support for new RVA20 boards (Pine64 Star64, StarFive VisionFive 2 Lite, Milk-V Mars CM) after the RVA23 transition. It's just that those users' distro stays frozen where it is. No new kernel, no new toolchain, no new GNOME.

So What Can You Actually Download Today (as of July 16, 2026)

This is the part of the post I verified myself directly. Ubuntu 26.04 LTS was released on April 23, 2026. Now, nearly three months later, here's the list of RISC-V images Canonical builds and hosts itself.

Canonical-built images (ubuntu.com/download/risc-v), checked 2026-07-16

  AllWinner Nezha                      24.04.4 LTS
  DeepComputing FML13V01               24.04.4 LTS
  Microchip PIC64GX1000 Curiosity Kit  24.04.4 LTS
  Microchip Polarfire SoC FPGA Icicle  24.04.4 LTS
  Milk-V Mars                          24.04.4 LTS
  Milk-V Mars CM                       24.04.4 LTS
  Pine64 Star64                        24.04.4 LTS
  SiFive Unmatched                     24.04.4 LTS
  Sipeed LicheeRV Dock                 24.04.4 LTS
  StarFive VisionFive 2                24.04.4 LTS
  StarFive VisionFive 2 Lite           24.04.4 LTS
  QEMU emulator                        26.04 LTS      <- only one

The only "platform" that can run an LTS built on the RVA23 baseline with Canonical support is the emulator. The physical boards on the list are the wrong generation. SiFive Unmatched's Freedom U740 is a quad-core RV64GC per the Debian wiki, so it has no vector unit at all, and the StarFive JH7110 (SiFive U74 core) family shared by VisionFive 2, Milk-V Mars, and Pine64 Star64 is something Canonical itself calls an RVA20 board. RVA20 has no vector at all — V first showed up as optional in RVA22.

So can physical RVA23 boards not run Ubuntu 26.04 at all? Not quite. There's a separate partner-built page, and it lists two SpacemiT K3 variants (CoM260 Kit, Pico-ITX) with Ubuntu 26.04 Server images. But you have to read Canonical's own warning at the top of that page as it stands.

These Ubuntu images are built and hosted by Canonical's partners, using Canonical's tools and standard build processes. They are provided as developer previews only, are not production-ready, and do not include Canonical's security updates or support.

Developer preview, not for production, no Canonical security updates or support included. For reference, the rest of the boards on that same partner page — ESWIN EBC7700/EBC7702, Milk-V Titan, SiFive HiFive Premier P550, DeepComputing FML13V01 — are all 24.04 images.

Summed up in one sentence: as of July 2026, there is no combination on RISC-V that runs Canonical's supported, latest LTS on physical hardware. Your choices are run it on the emulator, use an unsupported preview image, or stay on 24.04.

Physical RVA23 Silicon — SpacemiT K3

So how far along is physical hardware? The most concrete thing right now is the SpacemiT K3. The K3 Pico-ITX SBC and CoM260 SoM launched in May 2026, starting at around $299.

On paper it's impressive: 8 X100 "big" cores at up to 2.4GHz, plus 8 A100 AI cores supporting 1024-bit RVV1.0, up to 32GB of LPDDR5, PCIe Gen3 x4, even 10GbE SFP+. But the following two numbers are vendor claims — up to 60 TOPS of AI performance at INT4, and 130 KDMIPS said to be comparable to the RK3588. Both are figures from SpacemiT's spec sheet, not independently verified values.

The closest thing to an independent measurement is an early benchmark CNX Software published in January 2026. Disclosing the conditions first — a third party (Sander) logged into a remote K3 server provided by SpacemiT and ran sbc-bench v0.9.72, and CNX itself stated this "should be viewed as an early benchmark." The fact that the hardware was vendor-provided should be factored into how you read it.

With those conditions attached, here are the numbers.

  • 7-Zip single-core: X100 at 2736 MIPS vs. Raspberry Pi 5 at 3136 MIPS. Lower than the Pi 5.
  • aes-256-cbc single-core: K3 at 869,520.73k vs. Pi 5 at 1,367,736.32k. CNX qualified this as "at the same CPU frequency" and suggested this looked specific to this workload.
  • 7-Zip multi-core: a slight edge over the RK3588. But an important caveat comes with it — 16 cores are detected, yet 7-Zip and stress-ng only used 8.
  • Memory bandwidth: on the low side, only slightly better than the Pi 5.

Carrying over CNX's conclusion as-is: K3 is meaningful progress relative to other RISC-V SoCs, but compared to established Arm SoCs it isn't remarkable performance — only somewhat better than the RK3588.

And there's a line in the benchmark log that says more than the performance numbers do — the inxi output included in the same post.

Kernel: 6.12.16-generic arch: riscv64   Distro: Ubuntu 26.04 (Resolute Raccoon)
CPU: 16-core model: Spacemit X100  cache: L2: 10 MiB  Speed: 2200 MHz
Device-1: saturn-edp driver: spacemit_drm_drv v: N/A
API: OpenGL v: 3.3 vendor: mesa v: 24.0.1 renderer: softpipe
API: Vulkan  Message: No Vulkan data available.

renderer: softpipe. Read precisely, this means the display driver (spacemit_drm_drv) is loaded, but there's no 3D acceleration path, so Mesa has fallen back to a software rasterizer. Vulkan isn't detected at all — even though the K3 spec sheet lists an Imagination BXM4-64-MC1 GPU with Vulkan 1.3 support. (You do have to account for this being a remote server environment, but this is exactly the spot where a ready acceleration stack should have shown up.) RVA23 is just a CPU ISA agreement; it doesn't deliver a driver stack. This is a recurring pattern in the RISC-V ecosystem — even when the CPU core meets the standard, the GPU/VPU/NPU drivers next to it remain a vendor BSP problem.

Volume also needs a cold look. According to CNX citing an SCMP report, the previous generation SpacemiT K1 shipped just over 150,000 units. CNX's phrase for it was "not a huge number." That's the scale of today's RISC-V application-processor market.

In fairness, I should add that better parts have already been announced at the IP level. SiFive's Performance product page introduces the P800 series as RVA23 with 2x128 bit vectors, and the P570 Gen 3 as the core with the broadest support for RVA23 profile features. But this is licensable CPU IP, not a board I can order right now. It's safer to treat the lag between an IP announcement and silicon you can hold in your hand as a constant in this field.

Toolchains — LLVM in 2024, GCC in 2026

For a profile to be genuinely usable, the compiler has to know its name. That means being able to write -march=rva23u64 instead of hand-listing -march=rv64gcv_zbb_zvbb_.... Canonical illustrated this well in its profile explainer post — spelled out as an extension string, RVA23 looks roughly like this.

rv64gc_zicsr_zicntr_zihpm_zicbom_zicbop_zicboz_zicond_zimop_zcmop_zfh_zfa_zawrs_zbc_zvfh_
zvfhmin_zvbc_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkn_zvknc_zvknf_zvkng_zvks_zvksc_
zvksf_zvksg_zvl128b_zihintpause_zihintntl_svpbmt_svinval_svade_sstc_sscofpmf_ssccptr_...

This is where the gap between toolchains is fairly large. I checked the repositories directly.

LLVM got there early. rva23u64 and rva23s64 are already in llvm/lib/Target/RISCV/RISCVProfiles.td as of the release/19.x branch. LLVM 19 is effectively concurrent with RVA23's ratification (October 2024).

GCC was much later. Here's what checking shows.

gcc/config/riscv/riscv-profiles.def
  releases/gcc-14  -> file not present
  releases/gcc-15  -> file not present
  releases/gcc-16  -> rva20u64 rva22u64 rva23s64 rva23u64 rvb23u64

Even grepping gcc/common/config/riscv/riscv-common.cc, the strings rva22u64 and rva23u64 don't exist at all on the gcc-14 and gcc-15 branches. In other words, through GCC 15 there was no way at all to accept a profile name via -march. GCC 16.1 came out on April 30, 2026, and only with the 16 manual is the -march=[ISA|Profile|Profile_ISA|processor-string] syntax and the rva23u64 example documented. Notation like rva23u64_zacas, for appending extensions to a profile, was also settled here.

That's about 18 months from ratification to GCC support. It means Clang users were fine early on, while anyone building a distro with GCC had to wait. Given that most distros are built with GCC, this gap isn't academic.

Rust has a dedicated target. riscv64a23-unknown-linux-gnu is Tier 2 (excluding host tools), and the docs state This target will enable all mandatory features of rva23u64 by default.. You can add it right away with rustup target add riscv64a23-unknown-linux-gnu. It's worth remembering that Tier 2 means "builds are guaranteed, but automated testing is not."

Why Debian Stays on RV64GC

What's interesting in contrast to Ubuntu is Debian. The Debian wiki's sentence is short and clear.

The Debian port uses RV64GC as the hardware baseline and the lp64d ABI (the default ABI for RV64G systems).

RV64GC. No vector, no hypervisor. That's roughly RVA20-level, two generations behind the RVA23S64 Ubuntu requires.

This isn't Debian being lazy. It's that the two distros simply have different interests. Ubuntu signs commercial contracts with silicon vendors and ODMs and targets the next generation of products — if a partner is about to ship an RVA23 chip, it makes sense for the distro to get there ahead of time. Debian prioritizes running on hardware users already have in hand. And the RISC-V boards actually sitting on people's desks today are RV64GC things like VisionFive 2 and Mars.

The same fact — RVA23 hardware is still scarce — produces opposite conclusions. Ubuntu's take: "so let's go ahead and wait." Debian's take: "so we can't go yet." Neither is wrong.

When to Target RVA23, and When Not To

Summed up, the call breaks down like this.

When targeting RVA23 makes sense

  • You're picking silicon right now for a product shipping in 2027 or later. This is exactly why profiles exist — vendor alignment operates in the future tense.
  • Vector is central to your workload (codecs, crypto, inference kernels), and you want to eliminate the cost of maintaining both runtime dispatch and a scalar fallback. With RVA23 you can assume VLEN of 128 bits or more at compile time.
  • You need the hypervisor. Since H was optional under RVA22, making virtualization a requirement effectively means requiring RVA23-class hardware.
  • Your toolchain is Clang, or you can move to GCC 16 or later.

When it's not yet time

  • You need to run it on physical boards right now. As of today the only real option is roughly the SpacemiT K3, and the Ubuntu image for it is an unsupported developer preview.
  • Performance is the goal. K3's single-core measured lower than the Raspberry Pi 5 (7-Zip 2736 vs. 3136 MIPS). Now is not the time to pick RISC-V for performance. If you do pick it, the reason has to lie elsewhere — licensing, custom extensions, supply chain, regulation.
  • You need GPU acceleration. renderer: softpipe is your answer. An ISA profile doesn't hand you a driver.
  • You're on a Debian-family distro and already have RV64GC hardware. Leave it as is. There's no reason for Debian's baseline to move anytime soon.
  • You're expecting a security feature like control-flow integrity. Zicfilp/Zicfiss remain optional even under RVA23.

If your goal is running a RISC-V core directly on an FPGA yourself, this profile discussion is mostly beside the point — that side of the story is covered separately in Open FPGA & RISC-V Development 2026 Deep Dive - Yosys, NextPnR, IceStorm, Lattice ECP5, SiFive, BeagleV-Fire, Tang Nano, PULPino. A profile only ever solves the problem of "running someone else's binary on my chip."

Closing

I think RVA23 is a well-made spec. Mandating vector and hypervisor was a decision RISC-V genuinely needed to survive the binary-distribution market, and the ratification document doesn't hide that logic — it states it plainly. Giving compilers a guarantee they can actually rely on, like a 128-bit VLEN floor, is practical too.

At the same time, a spec being ratified and being able to actually work on top of that spec are still two different things, even now, 21 months later. Ubuntu raised its baseline, but the only RISC-V platform for the 26.04 LTS Canonical directly supports is the emulator, and Canonical itself states that images for physical RVA23 boards aren't for production. GCC only understood profile names starting this past April. The most advanced RVA23 chip's single-core performance measured lower than the Raspberry Pi 5, and its GPU runs on software rendering.

So I see RVA23 not as something to "use now," but as something to plan for now. If you're shipping a product in 2027–2028, RVA23 is a requirement that belongs on the negotiating table. If you need something running this quarter, 24.04 LTS and an RV64GC board are still the right answer. A profile's value lies in aligning tomorrow's hardware, not today's — and that's inherently something that takes time.

References

Discuss on Twitter • View on GitHub