

⾃ 2024 年 10 ⽉ RISC-V 国际基⾦会正式发布 RVA23 Profile 以来,该标准在业界获得了⼴泛的⽀持与响应。然⽽,在 Linux Kernel 层⾯,对 RVA23 mandatory 扩展的覆盖尚不完整。
前两天(2026年2⽉22⽇),Linux v7.0-rc1 准时发布。不知道⼤家有没有注意到 RISC-V 架构⽅⾯的⼀个细节:内核对 rva23u64 和 rva23s64 强制(mandatory)扩展的⽀持率,已然达到了 100%。

图1 RVA23 Mandatory 扩展内核⽀持率演进
(图片来源:徐国栋 RISCstar [8])
看着这条最终触顶 100% 的曲线,作为事件参与者,我感到非常欣慰。毕竟,这最后一段陡升,是我最近翻 Spec、敲代码、在邮件列表里跟人"吵架"换来的。就来聊聊这段⽇常。
01
谁在推动内核 RVA23 ⽀持的演进?
内核主线⽀持的推进,背后的主要驱动⼒来⾃产业界。
在 2025 年 7 ⽉的中国 RISC-V 峰会上,多家芯⽚⼚商公布了⽀持 RVA23 标准的芯⽚路线图(详⻅笔者的峰会总结 [6])。其中,进迭时空(SpacemiT)的 K3 于 2025年12⽉份率先完成了流⽚并发布开发板,成为市场上⾸款可以买到的 RVA23 芯⽚(云端体验已通过 Bianbu Cloud [5] 开启)。
图2 K3 研发时间轴(图⽚来源:进迭时空)
在代表 RISCstar 与进迭时空合作、推进 K3 ⽀持的过程中,我注意到 Linux 内核主线对 RVA23 的⽀持尚不完整。于是,在社区 Maintainer 的建议下,借着 K3 Upstream 起步的阶段,我梳理了内核中遗漏的 RVA23 mandatory 扩展,并在 K3 Basic Device Tree ⽀持的 Patchset [1] 中将缺失项加了进去。
这些补⻬的扩展涵盖了多个系列,包括:
-Sha 系列(Hypervisor 虚拟化):Shcounterenw, Shgatpa, Shtvala,
Shvsatpa, Shvstvala, Shvstvecd, Ssstateen
-Ss 系列(Supervisor 模式特性):Ssccptr, Sscounterenw, Sstvala,
Sstvecd, Ssu64xl
-Zicc 系列(缓存⼀致性保证):Ziccamoa, Ziccif, Zicclsm
-以及 Za64rs(原子操作 Reservation Set)
经历 v2、v3、v4 三个迭代版本后,最终获得社区认可并合⼊主线。
画外⾳:supm 扩展的社区争议
在提交 K3 DTS 时,Heinrich Schuchardt(Canonical)指出 ISA 字符串中缺少 supm(User-mode Pointer Masking),质疑芯⽚是否真正符合 RVA23。这引发了⼀场多⽅讨论,参与者包括 Conor Dooley(Microchip,RISC-V DT maintainer)、Samuel Holland(SiFive)、以及我。
争议的核⼼在于:supm 并不直接对应硬件电路,它描述的是"执⾏环境"为 U-mode 提供指针掩码的能⼒,实际的硬件实现是 Smnpm 或 Ssnpm。Samuel Holland 明确指出:K3 的 DTS ⾯向的是 S-mode ⽽⾮ U-mode,且不绑定特定版本的 S-mode 软件,因此不应在 DTS 中包含 supm。他建议 supm 只在内核中通过检测 Ssnpm/Smnpm 来合成(synthetically enable),⽽⾮从 DTS 解析。
最终社区达成共识:允许在 dt-bindings (extensions.yaml) 中描述 supm 的存在,但不允许在 DTS 的 ISA 字符串中包含 supm。我随后提交了专⻔的 supm patchset [7],为 supm 定义了 ISA extension ID 和依赖检查逻辑。
02
安家落户与 CPU Feature 导出
前⾯的 Device Tree 补⻬是基础性的、不可或缺的⼀步 - 它让内核第⼀次完整地"认识"了 RVA23 的全部 mandatory 扩展,也正是这⼀步将覆盖率推到了100%。但要让⽤户态程序也能感知和利⽤这些扩展,还需要进⼀步实现 CPU Feature Parsing(特性解析),并通过 cpuinfo 和 hwprobe 对⽤户态(Userspace)导出。
这也是我和 Andrew Jones(Qualcomm)协作的⼀部分。
在推进特性的解析与导出时,Andrew Jones ⽐我早⼀天在邮件列表发出了他的 Patchset [2],他增加了将 rva23u64 / rva23s64 作为专⻔的 Base ISA 进⾏解析的逻辑。⽽我的⼯作 [3] 则侧重于补⻬ S 扩展的对外 export。
在审阅了他的 Patchset 后,我针对其中的⼀些设计提出了修改意⻅,例如rva23u64 检测应基于 ISA_EXT(ground truth)⽽⾮ HWPROBE_EXT(导出⼦集)、commit 引⽤应指向 ratified 版本,以及 B 扩展是否应加⼊ hwprobe 等。
⽬前双⽅仍在讨论中,Andrew 提出了关于 hwprobe 导出策略的更深层问题:是导出所有扩展(包括 bundle 扩展),还是只导出独⽴扩展?这些讨论将影响后续 hwprobe 接⼝的设计⽅向。
期待这些⼯作能早⽇合⼊主线,⽬标是 v7.1,但也很有可能到 v7.2 才能完成。
花絮


图3 Reddit r/RISCV 帖⼦及 Tom Gall 的评论
我在 Reddit r/RISCV 上分享了这⼀进展 [4],很快收到了 RISC-V International CTO Tom Gall 的点赞,帖⼦⽬前获得了 60 个 upvote。这说明社区对 RVA23 在 Linux 主线中完整落地这件事⾮常关注 - 它不仅是⼀个技术⾥程碑,也是 RISC-V 软件⽣态⾛向成熟的信号。
关于作者
徐国栋 (Docular),RISCstar 中国区运营总监,20年 Linux 内核与平台软件专家。深耕 Arm 与 RISC-V 双⽣态,致⼒于代码上游化及开源落地,兼具技术深度与商业视野,常受邀参加国际顶会发表演讲。更多信息,欢迎⼤家点⼀点:https://docularxu.github.io
参考资料
[1] K3 Basic Device Tree Patchset (v4):
https://lore.kernel.org/all/20260110-k3-basic-dt-v4-0-d492f3a30ffa@riscstar.com/
[2] Andrew Jones - rva23u64 base behavior RFC:
https://lore.kernel.org/all/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/
[3] CPU feature parsing and hwprobe export Patchset:
https://lore.kernel.org/all/20260207-isa-ext-parse-export-v1-0-a64d3a8bc20a@riscstar.com/
[4] Reddit r/RISCV 帖⼦:
https://www.reddit.com/r/RISCV/comments/1rd3ke7/linux_70rc1_spacemit_k3_soc_lands_in_mainline/
[5] K3 云端体验介绍:
https://forum.spacemit.com/t/topic/932
[6] RISC-V Summit China 2025 峰会总结:
https://riscv.org/blog/risc-v-summit-china-2025-reflections-from-a-risc-v-software-contributor/
[7] supm extension patchset:
https://lore.kernel.org/all/20260125-supm-ext-id-v2-0-1e3b9714c860@riscstar.com/
[8] RVA23 in Linux Kernel evolution, interactive version:
https://docularxu.github.io/rva23/rva23-kernel-support-evolution.html
转载结束。本文不代表本人和任职机构观点