一直以来，龙蜥社区在 RISC-V 生态建设中持续投入，并积极贡献上游社区。RISC-V International Data Center SIG 第七次会议内容见下：

近期，RISC-V 基金会 Data Center SIG 月度会议于线上召开，本次会议邀请阿里巴巴达摩院郭任进行分享。会议由阿里巴巴宋卓主持。会议按惯例完成社区协作、反垄断与出口管制等合规提示后，进入本次核心议题：阿里巴巴达摩院郭任分享一项面向 RISC-V IOMMU 的 G-Stage Dirty Log 硬件加速机制提案，并与 RISC-V International 的 Rafael Sene 就后续以任务组（TG）方式推进达成初步共识。

郭任介绍，Dirty Log 是云数据中心虚拟机 Live Migration（热迁移） 的基础能力之一，主要服务于迁移过程中的 pre-copy 阶段：在虚机仍运行于源端时，需要持续识别并传输“被写脏”的页，避免频繁陷入软件开销大的页故障处理，从而显著提升迁移效率。

他指出，业界在 CPU 侧已有成熟的硬件加速路径（如部分架构提供的脏页记录能力），但在 Shared Guest Phyiscal Address（SGPA) 场景，虚机直通设备（pass-through DMA）可能复用 CPU 页表：即便 CPU 启用了 Dirty Log 加速，设备 DMA 产生的脏写也会让“仅 CPU 侧加速”变得不完整，导致系统层面仍无法正确/高效地收集脏页信息。

因此，本次提案的关键结论是：要让 Dirty Log 真正在云上“跑起来”，必须引入 IOMMU Dirty Log，与 CPU 侧机制协同，实现面向设备 DMA 场景的 系统级 Dirty Log 硬件加速闭环。

• 两类并行记录：每个缓冲对内部包含两类同步 buffer：
  • 记录被写脏的 GPA（Guest Physical Address）；
  • 记录与该 GPA 对应的 IOHGATP（用于区分其所属 G-stage 地址空间/虚机上下文）。通过同一索引对齐，软件可恢复“哪个虚机/哪个上下文的哪个 GPA 被写脏”。

郭任进一步给出面向 RISC-V IOMMU 的接口草案轮廓（当前为 v2）：

• 在 capability register 中增加能力位，标识支持 G-stage dirty log。

• 引入 G-Stage Dirty Log Control Register（GDLCR）：包含 enable、buffer size（按 entries 数量阶数配置）等字段。

• 引入 G-Stage Dirty Log Status Register（GDLSR）：提供当前活动缓冲对选择位（A/B）、A/B 满标志（并支持写 1 清除以便原子化处理）、以及当前活动缓冲 tail index 等。

• 定义两组缓冲区基址寄存器：GPA buffer A/B 与 IOHGATP buffer A/B（均以 PPN 形式给出基址）。

• 定义四类典型事件/中断：

• • A/B 缓冲对写满触发中断，提示软件拷出并清空；

  • 缓冲指针配置错误等异常；

  • 记录过程中的数据损坏类错误；

  • A、B 同时写满导致“脏页记录失效/丢失”，提示需要回退到全量扫描等恢复策略。

RISC-V International 的 Rafael Sene 在会上询问该提案后续将以 fast track 还是 TG/TSC 推进。郭任明确表示更倾向成立 TG，并给出了更大的组织化规划：拟筹备一个名为 “Device Shared Work Queue” 的任务组，将多项相互关联的扩展放在同一 TG 生命周期内统筹讨论与推进，包括：

• AIOE（用于共享硬件工作队列的基础入队能力）

• IOMMU GIPC（用于共享队列虚拟化/隔离等配套能力）

• IOMMU Dirty Log（用于共享队列与直通 DMA 场景下的 Live Migration 加速能力）

郭任补充说明：相较 dedicated work queue，共享 work queue 在迁移与资源调度上更具优势，但也更依赖 IOMMU 与虚拟化能力协同，因此希望以“场景驱动”的 TG 方式打包推进。

Rafael 对该思路表示认可，并指出一个重要信号：来自基金会董事会层面的方向中，2026 年的重点之一是云环境能力建设，而 Live Migration 是云的关键组成部分；因此该 TG 方向与组织目标高度一致，有望获得更积极的关注与推进动力。

字节跳动崔运辉在会上表示该方案“对迁移很有用”，总体认可提案方向。郭任也回应希望与字节跳动等社区伙伴进一步协作，结合双方在 CPU/IOMMU dirty log 方向的经验共同完善方案。

会议最后，宋卓总结：后续讨论将继续在邮件列表推进；郭任将依据模板完善 TG 页面与 Proposal for Work，在准备就绪后择机提交 TSC 评审。会议在感谢 Rafael 支持后结束。

RISC-V International Data Center SIG 召开线上双周例会。本次会议由郭任主要分享和成员共同评审并完善 Device Shared Work Queue（DSWQ）任务组（TG）Proposal for Work 文档，围绕“为何需要 TG、要做哪些规范工作、如何证明可行（PoC）以及如何组织生态协作”等关键点展开讨论。来自字节跳动、中兴通讯以及 RISC-V International 的多位代表参与交流，包括 Rafael Sene、Isaac Chute 等。

郭任在文档讲解中首先明确 TG 使命：为 RISC-V 构建支持 Device Shared Work Queue（设备共享工作队列）的规范体系，使其能够基于“可延迟写（deferable/deliverable write）事务”与 PASID/PID 等机制，实现面向异构设备的高密度 I/O 虚拟化与可迁移能力。

他对比了两类主流队列范式：

• DWQ（Dedicated Work Queue，专用队列）：典型形态为 SQ/CQ 队列对，位于主机内存，由设备拉取/更新；在云环境中往往“一个队列服务一个地址空间”，当 VM/进程密度极高时，需要成百上千甚至更多队列对支撑，成本与复杂度迅速上升。

• DSWQ（Device Shared Work Queue，设备共享队列）：通过设备侧固定宽度 I/O 端口接收来自主机的“可延迟写”命令提交，可在设计上覆盖海量地址空间（文档提到可扩展到百万级），更契合云数据中心的多租户与高密度 I/O 虚拟化需求。

郭任强调，DSWQ 已在多种互连标准与主流架构中形成趋势：包括 PCIe/CXL 等互连语义演进（会议中将其与 PCIe 的 DMWR 等术语类比）以及 x86/Arm 等体系结构已有对应指令/机制。基于此，他认为“RISC-V 没有理由不跟进该方向”，应尽快通过 TG 形成系统化规范与配套生态。

在“Why existing extensions are insufficient”章节中，郭任给出两类主要缺口：

• ISA（架构指令层）缺口

  RISC-V 当前缺少“向 DSWQ 入队命令”的标准化机制。对标业界，x86 有类似 ENQCMD 的能力、Arm 也有相应指令形态；同时还涉及 PASID/PID 的使用与映射/陷入处理机制（虚拟 PASID 到真实 PASID 的管理）。

• Non-ISA（以 IOMMU/虚拟化为核心）缺口

  现有 IOMMU 机制在 G-stage/进程上下文等方面仍不足以支撑“跨 VM 共享队列”的关键诉求（会议中以 PACID/PASID/PID 相关能力衔接为背景进行说明）。

  进一步地，为提升云上热迁移效率，IOMMU 侧还需要与系统级能力协同（例如前序会议已讨论过的 IOMMU Dirty Log 方向），否则 DSWQ 在 Live Migration 场景下的优势无法充分释放。

在“Objectives”章节中，郭任将 TG 的拟交付内容拆解为三条主线（并强调它们相互依赖、应在同一 TG 内整体推进）：

• AIOE（Atomic I/O Enqueue）：面向 DSWQ 的基础能力，定义指令与 CSR 等机制，解决“如何把命令可靠入队到设备共享队列”的问题。

• IOMMU GIPC（将 I/O 相关 G-stage 机制下沉到 Process Context）：用于更好地支撑 AIOE/DSWQ 在虚拟化与隔离场景中的落地。

• RISC-V IOMMU Dirty Log：面向 Live Migration，提升共享队列相关 I/O 路径下的迁移效率，并与 CPU 侧能力形成协同。

同时，郭任也在文档中加入“软件生态”视角的内容，用于保障规范不是“纸面设计”，而是可实现、可验证、可被社区复用，包括：VFIO/IOMMU（host/guest）、Linux PASID/IOASID 相关支撑、Linux DSWQ 基础设施、测试基础设施，以及迁移/加速器实例 demo 等。

会议讨论中，RISC-V International 的 Rafael Sene 与 Isaac Chute 提出了两点直接影响 TSC 评审质量的建议：

• Rafael：提案中需要明确 PoC（Proof of Concept）路径

  Rafael 指出，TSC 在评审 TG Proposal 及后续 ratification 计划时，一定会追问“如何证明规范可行且可复现”。因此建议在文档中补充一句或一段，明确 PoC 作为软件生态的一部分：TG 将在需要时推动 PoC 落地，用以展示规范“能工作、可复制、可验证”。

• Isaac：能否明确与主流发行版/生态伙伴的协作方式

  Isaac 关心当 PoC 与 Linux 相关工作推进时，是否需要考虑聚焦哪些发行版（如 Debian 等），以及如何 leverage RISC-V International 生态中“主流发行版成员”的资源参与验证与推广。

字节跳动崔运辉：DSWQ 相关软件开发进展与 Linux 内核侧具体需要做哪些工作？郭任回应：TG 的主目标是规范制定，但软件生态与 PoC/开源推进会作为重要配套来验证规范方向与可实现性，团队也在投入资源并计划逐步开源，与社区协作完善。

• 郭任将根据本次反馈继续完善 DSWQ TG Proposal：补充 PoC 描述、细化生态协作方式。

• Data Center SIG 将继续在邮件列表跟进讨论，推动提案进入 TSC 评审流程。

会议在感谢各方参与后结束。此次讨论标志着 Data Center SIG 正在把“共享队列 + 虚拟化 + 热迁移”这一云关键路径能力，从点状提案推进到任务组化、规范化与可验证的工程路线图阶段。