RISC-V TIME 寄存器的前世，今生与未来

窥见在历史遗留和碎片化硬件上构建软件的阻碍与解决方案

梓瑶 (Yao Zi)

自我介绍

@ziyao233 on GitHub 爱好是水 Linux/U-Boot 提交 包括 RISC-V 相关的修改

如果你还不知道 RISC-V 是什么

读作 risk-five 新一代标准开放的指令集 设计模块化，通过组合大量的“扩展”（extensions）适应不同场景 MCU：基础整数，压缩指令 桌面设备：浮点数、向量指令....

TIME 寄存器是啥

• RISC-V 的控制与状态寄存器（CSR）之一
  • 用户态可以读取，无需特权
• 以固定频率自动递增的计数器，反映现实时间
• 类似的计数器：
  • x86_64 的 RDTSC 指令
  • 龙架构的 Stable Counter
• 实际使用时，需要知道计数的频率以转化为现实时间
  • 如何获得计数频率？

如何获得计数频率？

• RISC-V 手册说：
  • The execution environment should provide a means of determining the period of a counter tick
  • 缺少具体的实现标准
• 事实标准们

如何获得计数频率：事实标准们

• 设备树的 /cpus/timebase-frequency
• ACPI 的 RHCT 表（RISC-V Hart Capabilities Table)
  • time_base_freq 成员
• 长期以来，用户态缺少获取 TIME CSR 频率的直接方式
  • /sys/firmware/devicetree：ACPI 系统不可用
• Linux v6.11 为 riscv_hwprobe 系统调用引入了 KEY_TIME_CSR_FREQ

曲折的标准化过程

• RISC-V Instruction Set Manual: Volume 1
  • v2.2 (2017.05.07): 包含在最基础的 I 扩展中
  • v20190608: 拆分出 Counter/Timer 扩展
    • I 扩展开始冻结，而 Counter/Timer 仍为草稿状态
    • 同时 Zicsr 也被独立出来
  • 三年的沉寂
  • 20220622（终于）: 以 Zicntr 为名字的扩展被批准
• 标准化的波折不是没有代价的

尴尬的局面

• RVA20 与 RVA22 标准冻结时，依赖的 Zicntr 仍未得到正式批准
• 新旧标准中 I 扩展隐含的内容不同，语义差别意味着扩展解析器需要更改
  • 工具链的 -march 参数
  • 设备树中 CPU 节点的 riscv,isa 属性

扩展解析器的修改

• 描述方式缺少对扩展和 ISA 文档版本的描述，无法确定该参考哪个版本的语义
• 工具链引入了 -misa-spec 参数
• Linux RISC-V 的 dt-binding
  • riscv,isa 参数已经无法改进
  • 考虑到与旧固件的兼容性，只能弃用旧参数另起炉灶
  • 新的 riscv,isa-extensions 属性
• Case... closed?

寄存器到底有没有

• 读取 TIME CSR 的指令在部分 RISC-V CPU 实现上裸机运行会报非法指令列外
  • 然而启动内核后同样的指令能够正常运行

能搜到一万个类似的 illegal instruction 报告

寄存器到底有没有

• 读取 TIME CSR 的指令在部分 RISC-V CPU 实现上裸机运行会报非法指令列外
  • 然而启动内核后同样的指令能够正常运行
• TIME CSR 不一定需要硬件实现
  • Implementation can ... emulate this functionality on behalf of less-privileged modes in M-mode software.
• 读指令确实报了例外，但 M 模式的固件承担了一切

RISC-V 的启动流程 (Thank you Ubuntu guys)

寄存器到底有没有

• 既然 M 模式固件模拟了访问操作，没有代码受伤的世界达成了？
• 只有 M 模式固件受伤的世界达成了
• 医者不能自医
  • M 模式的固件以及加载它的固件需要自行确定 TIME CSR 的可用性:
    • 主动检测读 TIME CSR 是否会报例外
    • 通过设备树识别可用的扩展

主动检测读 TIME 是否会报例外

• 提前设置一个 trap handler，并尝试读取 TIME 寄存器
• OpenSBI 即使用此方法
• 优点: 100% 准确
• 缺点: 依赖异常的检测可能被视为 dirty hack，存在上游接受度的问题

通过设备树识别 TIME 可用性

• riscv,isa: 不行！
  • 语义上 i 扩展隐含了 Zicntr
  • 标准化过程的遗产还在追我
• riscv,isa-extensions: 理应美好的解决方案
  • 大量未实现 TIME 寄存器的硬件，上游化到 Linux 的设备树仍然描述了 Zicntr 扩展
  • /* Zicntr should only be detected using traps */
  • devicetree describes hardware，怎会如此
    • 缺乏合适的机制仅让 M 模式固件后的应用得知 Zicntr 可用性

RISC-V 的启动流程 (Thank you Ubuntu guys)

动态修改设备树

• OpenSBI 已有检测控制寄存器可用性的基础设施
  • 可在模拟 TIME 寄存器时在 riscv,isa-extensions 中添加 Zicntr 扩展
  • "dirty hack" 集中在一处，避免重复工作
  • OpenSBI v1.7 已有初步实现
• 然而，迁移现存代码仍需要时间
  • U-Boot v2025.07 仍然无条件使用 TIME 寄存器
  • 由于破坏存量系统的代价，我们可能无法纠正已有设备树的 Zicntr 错误

动态修改设备树

• 理想方案与现实实践的差距
  • 快速迭代系统程序时，常常需要在 OpenSBI 后加载另一份设备树
  • 可能丢失 M 模式固件对设备树的更改
    • 这种问题此前已经存在，例如记录保留内存区域的 reserved-memory
    • 但由于固件对设备树的修改一般较少，启动程序有一定的“移植”行为
• 革命尚未成功，同志还需努力

一点个人的思考

• 老生常谈：存在更改可能性的标准，应该添加版本号以保证后向兼容性
  • riscv,isa-extensions 仍缺乏相应的机制
• 存在兼容性需求的场合，不彻底的修复只会把问题越拖越大
• 硬件上的灵活性需要软件上的额外工作抹平
  • OpenSBI 等 M 模式固件正支持越来越多此类功能
  • 只是灵活标准的必然结果，还是硬件设计已经剑走偏锋？

参考链接

• 由 20190608 标准的变更引起的如何处理标准变化的讨论
• Linux 内核弃用 riscv,isa 属性的提交
• OpenSBI 动态修改设备树的实现
• RISC-V 非特权指令集手册 v2.2

感谢聆听

也感谢所有创在第一线的 RISC-V 基建人