一直以来，龙蜥社区在 RISC-V 生态建设中持续投入，并积极贡献上游社区。为加速 RISC-V 在数据中心场景的能力补齐与规模化落地，RISC-V International Data Center SIG 近期将例会节奏由月度调整为双周。以下为第六次会议内容：
RISC-V 架构中引入持久化内存缺口
近期，RISC-V 基金会 Data Center SIG 月度会议于线上召开，来自阿里云、中兴通讯、Rivos、RISC-V 国际基金会等企业的宋卓、王宝林、孙浩、郭任、贾云翔、Snehasish、Beeman、Rafael 等 13 位委员及代表参会。会议由宋卓先生主持，重点围绕“在 RISC-V 架构中引入持久化内存（Persistent Memory，PMem）相关支持”的方向展开讨论。
本次会议邀请阿里云王宝林以及阿里巴巴达摩院孙浩进行分享，王宝林长期负责 龙蜥社区内核内存子系统并参与上游维护，他从云计算实际工作负载出发，介绍了 PMem 的产业背景、数据中心应用价值以及 RISC-V 当前在相关指令/语义支持方面的缺口，并建议在社区层面推动形成面向 PMem 的标准化工作。
PMem 在云数据中心的现实需求：以 Redis/数据库场景为例
王宝林指出，PMem 具备字节寻址、高密度与直接持久化等特性。尽管 Intel 已宣布 Optane PMem 产品线停止，但 PMem 的研究与应用并未停止，产业界仍在持续投入。更重要的是，PMem 在云场景已经验证了价值：例如在云数据库/缓存系统（如 Redis）中，结合 PMem 可构建混合内存架构，在保持高吞吐的同时减少传统方案的周期性延迟抖动，并提升实例异常重启后的恢复效率。
他进一步强调，在数据中心落地 PMem 的关键不止在“介质可持久化”，还在于系统能否提供可靠的持久化语义保证：若缺乏明确的持久化点与配套机制，业务往往仍需依赖持久化云盘兜底，从而引入额外成本。
来自 Akeana 的 David Weaver 在讨论中表达了强烈支持。他提到自己曾在 Sun 与 Oracle 工作，数据库公司长期对 PMem 非常关注；他认为若 RISC-V 要严肃进入数据中心，PMem 相关能力必须补齐，“如果我们要认真做 RISC-V 数据中心生态，就需要把这件事做起来”。
作为 TSC（Technical Steering Committee）成员，David 也给出了清晰的推进路径建议：
- 对 TSC 的汇报重点不应是硬件实现细节，因为硬件设计属于后续任务组（TG）工作的范畴。
- TSC 需要先理解两点：为什么需要（动机与价值），以及准备做什么（任务组的工作范围与交付物）。
他建议提案应明确三类核心工作：定义持久化模型（persistency model）、定义对 ISA 的影响/原语（例如 flush 到持久化点的指令语义），以及讨论持久化顺序与相关互连/协议协作等问题。
社区关切：最终产出落在哪里？——ISA 扩展是核心方向
会上，来自社区的 Victor Lu 也提出了典型问题：RISC-V 以 ISA 为核心，本议题涉及较多系统特性，最终产出将如何与 ISA 对齐？
主持人宋卓与 David 等回应称，若后续推动成立 TG，该方向最终将形成面向 RISC-V 的架构/ISA 扩展建议（例如“将指定地址数据 flush 到持久化点”的指令或原语），并在规范层面给出一致语义；至于底层硬件实现方式，可由各厂商在遵循规范的前提下选择具体实现路径。
会议后段，阿里巴巴达摩院孙浩补充表示：硬件实现应当基于清晰的 RISC-V 规范。目前 RISC-V 缺乏对应 spec，因此应优先推动形成规范文本与语义定义，硬件实现可在此基础上由不同实现方展开，并参考其他架构既有经验逐步细化。
RISC-V 数据中心的潜在缺口与改进方向
为持续推动 RISC-V 在数据中心与服务器场景的可用性与可移植性，RISC-V International Data Center SIG 召开线上双周例会。本次会议由阿里巴巴宋卓主持，并邀请来自中兴通讯的贾云翔（Yunxiang Jia）从服务器视角系统梳理当前服务器相关规范中的潜在缺口与改进方向。来自 Rivos、字节跳动、阿里巴巴及 RISC-V International 的多位代表参与讨论并提出关键建议。
服务器视角的“缺口清单”：希望补强的能力点有哪些？
贾云翔介绍了服务器视角的“缺口清单”概要解读，主要覆盖以下几个方面：
- ISA 扩展建议
在现有服务器规范/配置中，一些 ISA 层扩展并非强制，但在安全性、可维护性等方面具有价值，贾云翔建议在服务器平台规范中评估补充（发言中举例提到若干扩展方向）。
- PMU（性能监控）事件完善
当前规范条目（发言中提及 SPM 030/040）偏重 PCIe inbound 事件定义；他认为 outbound PCIe 事件同样重要，应纳入规范。
另外，关于部分 CMO/缓存一致性相关事件 的标准化需求，他提到 Performance Events Task Group 可能已有相关工作，希望能与服务器规范衔接、视情况纳入。
- 调试/开发者能力（Debug capability）相关条目
他指出现有调试能力清单与 RISC-V Debug/Trace 相关规范版本之间存在差异，且有些能力（例如 program buffer 等）对开发调试很关键，希望服务器平台规范能更好覆盖。
- Trace（跟踪）能力
他建议在服务器规范中提高对 trace 的要求，至少支持某类 trace 形态（发言中倾向 E-Trace），并希望补充更明确的技术要求描述。
- Watchdog / Timer（看门狗与计时）
他认为 watchdog 对系统故障恢复很重要，当前要求不足；同时提到可参考 Arm 相关规范中关于 clock/time 的写法与约束。
- 其他：复位/电源管理/CSR、以及 CXL 集成等
他提到部分复位、电源管理与 CSR 等能力在当前版本中存在缺失；此外也提到了 CXL 相关内容，希望后续能在服务器平台规范中补齐或明确。
Rivos：规范的“取舍原则”——服务器规范聚焦 OS 可移植性，不强制 Machine Mode/外部调试能力
Rivos 的 Vedvyas Shanbhogue 在讨论中提出了非常关键的规范取舍原则
- 服务器 SoC/平台规范以及 ISA Profiles 的核心目标，是保证 可移植操作系统/Hypervisor 在低于 M-mode 的特权级上运行的一致性能力；
- 因此，许多 Machine Mode 才可见、或偏 外部调试/外部 trace（对 OS 不可见）的能力，之所以未被纳入强制要求，并非遗漏，而是有意为之的设计选择；
- 这类似于 Arm SBSA 等规范并不强制某些更高特权级能力。未来如果社区定义“Machine Mode Profile”，再把这类能力纳入会更合理。
这一点也帮助 SIG 成员对“哪些能力应该进入服务器平台强制项、哪些应留给实现选择”形成更清晰的边界认识。贾云翔表示会进一步消化该原则，并重新评估条目归类方式。
Trace 讨论升温：E-Trace 还是 N-Trace？SIG 需要形成偏好以利于软件可移植性
围绕 Trace，Vedvyas 进一步追问了一个对未来版本非常关键的问题：如果未来要把“自托管（self-hosted）trace”纳入 server SoC/平台规范，就必须在 E-Trace 与 N-Trace 之间做出倾向，否则两者都“可选”会削弱对可移植软件的价值。
针对此问题，贾云翔从个人角度表达更倾向 E-Trace，并希望进一步完善其规格细节；Vedvyas 表示个人也赞同，但更希望 Data Center SIG 形成明确立场/建议，以便未来规则制定与版本演进。
Watchdog/Timer 的必要性答疑：与 PMU Counter 的角色不同
字节跳动的崔云辉就 watchdog/timer 提问：既然已有 PMU counter，为何仍需要 watchdog 或独立 timer 硬件？
贾云翔回应：watchdog/timer 更多面向固件/更高特权级（偏 machine mode）场景，用于系统故障恢复与可靠性保障；崔云辉确认理解其适用范围。同时，Vedvyas 也补充：服务器 SoC 规范对 time 已有明确要求（例如 1ns 分辨率、64-bit 等），可满足长期不回绕等目标。
CXL：从“是否需要”到“如何写进规范”——类型演进与版本门槛成为焦点
CXL 部分引发了进一步讨论。字节跳动的何爽对 CXL 的必要性提出疑问：当前 CXL 是否仍偏研究探索，是否会真实落地？
主持人宋卓回应：CXL 不仅面向 AI，也在数据库与云场景有用例与业务价值，应当成为 RISC-V 服务器能力考虑的一部分。阿里巴巴薛帅补充：在云存储中“扩展内存（expander memory）”是常见使用方式。
接着，Vedvyas 则从规范制定角度补充了两点洞察：
- CXL 规范整体“可选项较少”，并配套合规测试，相比 PCIe 的高可选性，往往难点在于“除了要求实现 CXL 规范本身，还需要额外规定什么”；
- 他们正在考虑提出更明确的版本约束：如果集成 CXL，建议至少从 CXL 2.0 起步，避免 CXL 1.0/1.1 在 Root Complex 上引入额外复杂性（例如 RCRB 等历史包袱）。他在会上征询与会者是否认可“2.0 或更高”的方向。贾云翔表示倾向认可，但是否在规范中写成明确约束仍需进一步评估。
此外，Vedvyas 也提到：PM、电源状态与唤醒、以及 CXL 集成等内容，正在 Server SoC2 Task Group 中推进；初版未纳入属阶段性取舍，欢迎把需求带到 SoC2 TG 进一步讨论。
下一步：材料进入邮件列表，与 Server SoC/平台 TG 联动推进
会议最后，宋卓建议贾云翔将本次“缺口清单”与材料通过 Data Center SIG 邮件列表共享，以便与其它 SIG/TG（尤其是 Server SoC TG 等）开展联动协作。贾云翔确认将把文档发送至相关 TG，推动后续对齐与吸收。
随着服务器场景标准化进入深水区，Data Center SIG 也将围绕“可移植 OS 视角的强制项边界”“Trace 取舍建议”“CXL 版本门槛与集成规则”等议题继续形成更明确的社区共识，并通过与相关 TG 的协作推进到规范条文层面。
—— 完 ——
