Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 已批准的规范，与能运行它的硬件之间的落差
为什么「规范」是 RISC-V 独有的东西
RVA23 实际强制了什么 — V 和 H
软件先跑了一步 — Ubuntu 的 RVA23S64 基线
那么今天到底能下载什么(截至 2026 年 7 月 16 日)
实体的 RVA23 硅片 — SpacemiT K3
工具链 — LLVM 是 2024 年，GCC 是 2026 年
Debian 为什么还停留在 RV64GC
什么时候该瞄准 RVA23，什么时候不该
结语
参考资料

引言 — 已批准的规范，与能运行它的硬件之间的落差

RISC-V 的故事大体逃不出两种腔调。要么是「开放 ISA 将改变世界」，要么是「它还是个玩具」。这两种都没什么用。从业者真正想知道的只有一件事——现在把它定为目标，哪些能成，哪些不能。

本文把这个问题押在 RVA23 这一个规范上来回答。RVA23 于 2024 年 10 月 21 日获得批准(RISC-V International 的公告，文档本身写着Version 1.0, 2024-10-17: This document is in Ratified state.)，此后已经过去 21 个月。在这段时间里，Ubuntu 把这个规范提升为最低要求，并在其上构建了一个 LTS 版本。规范也就从「标准文本」升级成了「产品要求」。

然而今天(2026 年 7 月 16 日)打开 Canonical 的 RISC-V 下载页面会发现，能拿到 26.04 LTS 镜像的平台只有一个，QEMU 模拟器。剩下的十一款实体开发板全都只能拿到 24.04.4 LTS。这道落差正是本文要谈的主题。

为什么「规范」是 RISC-V 独有的东西

写 x86 或 Arm 代码时，不用担心「这颗 CPU 有没有乘法指令」。在 RISC-V 上却要担心。因为模块化本来就是设计目标——扩展是可以挑着装的，供应商甚至还能自己加装定制扩展。

在嵌入式场景里，这是优点，因为所有软件都是自己编译的。问题出在把二进制分发给别人的市场上。批准文档的开篇相当坦率地承认了这层张力。

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.

同一份文档在下一段说得更直白：如果不通过规范提前对齐，RISC-V 将没有竞争力(Without proactive alignment through RVA profiles, RISC-V will be uncompetitive)，理由是——某个供应商实现了某个特性，只要其他供应商没跟上，二进制发行版就不会用这个特性，结果大家都吃亏。

这就是核心所在。规范不是硬件特性，而是硬件供应商之间的协议。软件生态系统挑的是自己实际观测到的最小公分母，不会因为规格表好看就买账。

所以文档才明确写道——要维持对齐、提高竞争力，必需扩展的集合就必须一代比一代增加(the mandatory set of extensions must increase over time in successive generations of RVA profile)。RVA23 存在的理由，就是这一句话。

RVA23 实际强制了什么 — V 和 H

规范分成两支。规定用户态可见特性的是 RVA23U64，规定管理态(也就是内核所期望)特性的是 RVA23S64。后面会看到，Ubuntu 要求的是 S64 这一支。

把批准文档里 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).

清单里真正分量最重的是第一行。批准文档自己加的注解是 V was optional in RVA22U64.。而这是可以核实的事实——翻开 RVA22 规范原文，写的是 RVA22U64 has four profile options (Zfh, V, Zkn, Zks)。向量当时是可选的。

这里有个经常被忽略的细节：V 同时锁定了向量长度。向量扩展规范写着 The V vector extension depends upon the Zvl128b and Zve64d extensions.，而 Zvl128b 意味着 VLEN 至少 128 位。也就是说，一颗满足 RVA23 的芯片，编译器可以假设的不只是「有向量单元」，而是「至少有 128 位的向量寄存器，并且能做 64 位浮点向量运算」——不需要运行时分发。

在管理态一侧(RVA23S64)，新增必需项里代价最高的是 Sha，就是它。文档里称之为 augmented hypervisor extension，实质上是把 H 扩展(虚拟化)加上 Ssstateen、Shcounterenw、Shvstvala、Shtvala 等打包在一起。而 H 在 RVA22S64 里同样是可选项——RVA22 原文中，H 位于 RVA22S64 Optional Extensions 一节里。

归纳一下，RVA23 的头条就是这个：RVA22 中可选的向量和虚拟化，如今双双变成了必需项。这是一个真正会拉高硅片面积和验证成本的要求，不是免费的对齐。

还有几处不太为人知的决定，也值得一并看看。

标量密码学被拿掉了。RVA22 里可选的 Zkn/Zks，在 RVA23 的选项清单里已经不存在。文档的理由很清楚——向量现在已经是必需项，而向量密码学远比标量快，所以两边都该转去用向量密码学。
控制流完整性仍然是可选的。Zicfilp(着陆点)和 Zicfiss(影子栈)在 RVA23U64 里属于 expansion option，也就是可选。不要仅仅因为一颗芯片写着 RVA23，就指望它具备相当于 Arm BTI/PAC 的防护。
Zacas(比较并交换)是 development option。也就是说现在是可选的，预计下一代才会变成必需。不能因为是 RVA23 芯片就假设它有 CAS。

软件先跑了一步 — Ubuntu 的 RVA23S64 基线

故事从这里开始变得有意思。通常是硬件先出，软件再跟上。Ubuntu 这次反着来。

Canonical RISC-V 下载页面上的公告写得很准确。

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.

值得注意的是，要求的对象不是 U64，而是 RVA23S64，正是这一支。正如前面所见，S64 强制包含 Sha，也就是虚拟化。跑一个桌面镜像其实并不需要虚拟化扩展，但如果把整个规范当作基线，它就会一并被带进来。

Canonical 在2026 年 2 月的回顾文章里说明了这个决定背后的逻辑——为了避免生态碎片化，并与硬件合作伙伴保持同步。同一篇文章也给出了对被留下的用户的回应。

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.

这句话应该被公平地解读。这不是「被抛弃」。24.04 LTS 配合 Ubuntu Pro 最长可以支持到 15 年。Canonical 甚至表示，即便在 RVA23 转型之后，也追加支持了新的 RVA20 开发板(Pine64 Star64、StarFive VisionFive 2 Lite、Milk-V Mars CM)。只是这些用户的发行版会停在原地——没有新内核，没有新工具链，没有新版 GNOME。

那么今天到底能下载什么(截至 2026 年 7 月 16 日)

这是本文中我亲自核实的部分。Ubuntu 26.04 LTS 已于 2026 年 4 月 23 日发布。将近三个月过去后的今天，Canonical 自己构建并托管的 RISC-V 镜像清单是这样的。

Canonical 自建镜像(ubuntu.com/download/risc-v)，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      <- 唯一

唯一能以 Canonical 支持的方式，运行构建在 RVA23 基线之上的 LTS 的「平台」，是模拟器。清单里的实体开发板世代都不对。SiFive Unmatched 的 Freedom U740 按 Debian Wiki 的说法是四核 RV64GC，根本没有向量单元；而 VisionFive 2、Milk-V Mars、Pine64 Star64 共用的 StarFive JH7110(SiFive U74 核心)系列，是 Canonical 自己称为 RVA20 开发板的那类东西。RVA20 里压根没有向量——V 是在 RVA22 里才作为可选项首次出现的。

那么实体的 RVA23 开发板就完全跑不了 Ubuntu 26.04 吗——倒也不是。另外有一个合作伙伴构建页面，上面挂着两款 SpacemiT K3(CoM260 Kit、Pico-ITX)的 Ubuntu 26.04 Server 镜像。但需要照原样读一下那个页面顶部 Canonical 自己给出的警告。

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.

开发者预览版，非生产就绪，不包含 Canonical 的安全更新与支持。顺带一提，同一个合作伙伴页面上剩下的开发板(ESWIN EBC7700/EBC7702、Milk-V Titan、SiFive HiFive Premier P550、DeepComputing FML13V01)全部都是 24.04 镜像。

用一句话概括就是：截至 2026 年 7 月，在 RISC-V 上不存在能用实体硬件运行 Canonical 支持的最新 LTS 的组合，一个都没有。要么用模拟器跑，要么用没有支持的预览镜像，要么停在 24.04——三选一。

实体的 RVA23 硅片 — SpacemiT K3

那么实体硬件走到哪一步了?目前最具体的东西是 SpacemiT K3。K3 Pico-ITX SBC 和 CoM260 SoM 已在 2026 年 5 月发布，299 美元起就能买到。

规格表看上去很亮眼：8 颗 X100「大核」最高 2.4GHz，再加 8 颗支持 1024 位 RVV1.0 的 A100 AI 核心、最高 32GB LPDDR5、PCIe Gen3 x4，甚至还有 10GbE SFP+。但以下两个数字，终归只是厂商自己的说法——INT4 下最高 60 TOPS 的 AI 性能，以及号称与 RK3588 相当的 130 KDMIPS。这两个都是 SpacemiT 规格表上的数字，不是独立验证过的值。

比较接近独立测量的，是 CNX Software 在 2026 年 1 月公开的早期跑分。先说明一下条件——这是第三方(Sander)登录 SpacemiT 提供的远程 K3 服务器、跑了 sbc-bench v0.9.72 的结果，CNX 自己也明确表示「应当把它当作早期跑分来看」。硬件由厂商提供这一点，读的时候要打个折扣。

带着这些条件来看，数字是这样的。

7-Zip 单核:X100 为 2736 MIPS，Raspberry Pi 5 为 3136 MIPS。比 Pi 5 低。
aes-256-cbc 单核:K3 为 869,520.73k，Pi 5 为 1,367,736.32k。CNX 加了「在相同 CPU 频率下」这个前提，并认为这看起来是这个工作负载特有的现象。
7-Zip 多核:略微领先 RK3588。但附带一个重要的说明——系统识别出 16 个核心，但 7-Zip 和 stress-ng 只用了 8 个。
内存带宽:偏低，只比 Pi 5 略好一点。

照搬 CNX 的结论：相对其他 RISC-V SoC 而言，K3 是有意义的进步，但和成熟的 Arm SoC 相比算不上出色的性能，大致只比 RK3588 好一点点。

而跑分记录里有一行比性能数字更能说明问题。同一篇文章里附的 inxi 输出如下。

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。准确地读，意思是显示驱动(spacemit_drm_drv)已经加载，但没有 3D 加速通路，Mesa 因此回退到了软件光栅化器。Vulkan 则完全没被检测到——尽管 K3 规格表上写着 Imagination BXM4-64-MC1 GPU 支持 Vulkan 1.3。(这是远程服务器环境，这一点需要打折扣，但如果加速栈已经就绪，本该在这里被检测到。)RVA23 只是 CPU ISA 层面的协议，并不会附带交付驱动栈。这是 RISC-V 生态里反复出现的模式——即便 CPU 核心满足了标准，它旁边的 GPU、VPU、NPU 驱动依然是厂商 BSP 层面的老问题。

出货量的问题也得冷静看待。据 CNX 援引 SCMP 的报道，上一代的 SpacemiT K1 出货量在 15 万台左右。CNX 的原话是「不算大的数量」。这就是今天 RISC-V 应用处理器市场的体量感。

公平起见也该补充一句：在 IP 层面，更强的东西其实已经发布了。SiFive 的 Performance 产品页面把 P800 系列介绍为 RVA23 with 2x128 bit vectors，把 P570 Gen 3 介绍为对 RVA23 规范特性支持最全面的核心。但这是可授权的 CPU IP，不是我现在就能下单的开发板。IP 发布和拿得到手的硅片之间的时间差，最好被当作这个领域的一个基本常数来看待。

工具链 — LLVM 是 2024 年，GCC 是 2026 年

一个规范要真正好用，编译器得先认得它的名字。也就是说要能写 -march=rva23u64，而不是手动罗列 -march=rv64gcv_zbb_zvbb_...。Canonical 在规范解读文章里很好地展示了这一点，把 RVA23 展开成扩展字符串大致是这样。

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_...

这里工具链之间的差距相当大。我直接查了仓库。

LLVM 很早就跟上了。llvm/lib/Target/RISCV/RISCVProfiles.td 里，rva23u64 和 rva23s64 在 release/19.x 分支就已经存在。LLVM 19 与 RVA23 的批准(2024 年 10 月)基本上是同一时期。

GCC 晚了很多。查一下是这样的。

gcc/config/riscv/riscv-profiles.def
  releases/gcc-14  -> 文件不存在
  releases/gcc-15  -> 文件不存在
  releases/gcc-16  -> rva20u64 rva22u64 rva23s64 rva23u64 rvb23u64

即便对 gcc/common/config/riscv/riscv-common.cc 做 grep，gcc-14 和 gcc-15 分支里也根本没有 rva22u64、rva23u64 这两个字符串。也就是说，直到 GCC 15，都完全没有用 -march 接受规范名称的能力。GCC 16.1 于 2026 年 4 月 30 日发布，直到 16 手册里，-march=[ISA|Profile|Profile_ISA|processor-string] 的语法和 rva23u64 的示例才被写进文档。像 rva23u64_zacas 这种在规范上追加扩展的写法，也是在这里定下来的。

从批准到 GCC 支持，大约花了 18 个月。用 Clang 的人早就能用了，用 GCC 构建发行版的一方则得等着。考虑到大多数发行版都是用 GCC 构建的，这个差距并不只是学术意义上的。

Rust 有专门的目标三元组。riscv64a23-unknown-linux-gnu 属于 Tier 2(不含主机工具)，文档里写着 This target will enable all mandatory features of rva23u64 by default.。用 rustup target add riscv64a23-unknown-linux-gnu 就能直接添加。值得记住的是，Tier 2 的意思是「保证能构建，但不保证自动化测试」。

Debian 为什么还停留在 RV64GC

和 Ubuntu 对照起来有意思的是 Debian。Debian Wiki 的说法又短又明确。

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

RV64GC。没有向量，也没有虚拟化。大致相当于 RVA20 的水平，与 Ubuntu 要求的 RVA23S64 相差了两代。

这不是因为 Debian 懒。只是两个发行版的利益诉求不同。Ubuntu 与硅片厂商、ODM 签订商业合同，瞄准下一代产品——如果合作伙伴计划推出 RVA23 芯片，发行版提前到位是合理的。Debian 优先考虑的是在用户手上已有的硬件上能跑起来。而今天真正摆在人们桌面上的 RISC-V 开发板，是 VisionFive 2、Mars 这类 RV64GC 的东西。

同一个事实(RVA23 硬件仍然稀缺)，得出了完全相反的结论。Ubuntu 的想法是「所以我们先走一步，等着」，Debian 的想法是「所以现在还不能走」。两边都没有错。

什么时候该瞄准 RVA23，什么时候不该

归纳起来，判断可以这样区分。

适合把 RVA23 定为目标的情况

正在为 2027 年以后上市的产品挑选硅片。规范存在的理由正是这个——厂商对齐是以未来时态运作的。
向量是工作负载的核心(编解码器、加密、推理内核)，并且想去掉同时维护运行时分发和标量回退这两套逻辑的成本。有了 RVA23，就可以在编译期假设 VLEN 至少 128 位。
需要虚拟化。既然 H 在 RVA22 里是可选的，把虚拟化定为要求，实际上就等于要求 RVA23 级别的硬件。
工具链是 Clang，或者能升级到 GCC 16 以上。

还不到时候的情况

现在就得在实体开发板上跑起来。截至今天，选择大致只有 SpacemiT K3，而 Ubuntu 镜像还是没有支持的开发者预览版。
目的是性能。K3 的单核跑分低于 Raspberry Pi 5(7-Zip 2736 对 3136 MIPS)。现在还不是因为性能去选 RISC-V 的时候。如果要选，理由应该在别处——授权、定制扩展、供应链、法规。
需要 GPU 加速。renderer: softpipe 就是答案。ISA 规范不会给你驱动。
用的是 Debian 系发行版，并且已经有 RV64GC 硬件。维持现状就好。Debian 的基线短期内没有理由挪动。
期待控制流完整性之类的安全特性。Zicfilp/Zicfiss 在 RVA23 里依然是可选的。

如果目的是用 FPGA 自己跑 RISC-V 核心，规范这套讨论基本上无关——那部分内容在开源 FPGA 与 RISC-V 开发环境一篇里另行讨论过。规范终究只是用来解决「在我的芯片上跑别人做的二进制」这一个问题的东西。

结语

我认为 RVA23 是一份做得不错的规范。把向量和虚拟化定为必需项，是 RISC-V 要在二进制分发市场里生存下去必须做的决定，批准文档自己也没有回避这层逻辑，直接写了出来。像 VLEN 至少 128 位这样的下限，让编译器有了真正能依赖的保证，这一点也很务实。

与此同时，规范获得批准，和能在这份规范之上真正干活，即便过了 21 个月的今天，依然是两回事。Ubuntu 抬高了基线，但 Canonical 直接支持的 26.04 LTS 唯一的 RISC-V 平台是模拟器，而实体 RVA23 开发板的镜像，Canonical 自己明确说了不是给生产环境用的。GCC 直到今年 4 月才听懂规范的名字。目前最领先的 RVA23 芯片，单核性能测出来比 Raspberry Pi 5 还低，GPU 则靠软件渲染在跑。

所以在我看来，RVA23 不是「现在就用」的东西，而是现在就该规划的东西，正是如此。如果打算在 2027 到 2028 年推出产品，RVA23 就是该摆上谈判桌的要求。如果这个季度就需要能跑起来的东西，24.04 LTS 加 RV64GC 开发板依然是正确答案。规范的价值在于让明天的硬件对齐，而不是今天的硬件，而这件事本来就需要时间。