当前位置:首页>Linux>[转载]Linux 7.0:RVA23 Mandatory 扩展覆盖率达 100%

[转载]Linux 7.0:RVA23 Mandatory 扩展覆盖率达 100%

  • 2026-09-02 20:21:38
[转载]Linux 7.0:RVA23 Mandatory 扩展覆盖率达 100%
健哥按:RVA23是RISC-V国际协会(下文的国际基金会)正式发布的第一部分服务器规范。指令集是软硬件的接口,明确了指令集,固件和操作系统就可以据此构建,有了这样的操作系统,上次软件就可以利用这些指令集更好的完成服务器等高性能场景的任务。
原文链接:
以下是转载正文:

⾃ 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


转载结束。本文不代表本人和任职机构观点

最新文章

随机文章