一直以来，龙蜥社区在 RISC-V 生态建设中持续投入，并积极贡献上游社区。RISC-V International Data Center SIG 第七次会议内容见下：
RISC-V IOMMU 的 G-Stage Dirty Log 硬件加速机制提案
近期，RISC-V 基金会 Data Center SIG 月度会议于线上召开，本次会议邀请阿里巴巴达摩院郭任进行分享。会议由阿里巴巴宋卓主持。会议按惯例完成社区协作、反垄断与出口管制等合规提示后，进入本次核心议题：阿里巴巴达摩院郭任分享一项面向 RISC-V IOMMU 的 G-Stage Dirty Log 硬件加速机制提案，并与 RISC-V International 的 Rafael Sene 就后续以任务组（TG）方式推进达成初步共识。
从 CPU 到 IOMMU：Dirty Log 加速要做“系统级闭环”
郭任介绍，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 硬件加速闭环。
方案核心：基于 Ping-Pong Buffer 的“低成本不丢失”记录机制
在实现路径上，郭任重点介绍了本提案区别于其他思路（例如 PRI 机制）的设计取舍：本方案采用 Ping-Pong Buffer 结构，目标是在硬件成本更可控的前提下，避免记录窗口切换时漏记脏页。
- 双缓冲对（A/B）：当 A 缓冲对写满后自动切换到 B 持续记录，软件侧再异步拷出并清空 A；随后反向切换，实现“你写我清、轮转不断档”。
- 两类并行记录：每个缓冲对内部包含两类同步 buffer：
- 记录被写脏的 GPA（Guest Physical Address）；
- 记录与该 GPA 对应的 IOHGATP（用于区分其所属 G-stage 地址空间/虚机上下文）。通过同一索引对齐，软件可恢复“哪个虚机/哪个上下文的哪个 GPA 被写脏”。
与会嘉宾反馈 Ping-Pong Buffer 结构不够灵活，需要改进，作者接受建议，并会在新版本中改进。
规范接口草案：能力位、控制/状态寄存器、缓冲区基址与中断事件
郭任进一步给出面向 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 同时写满导致“脏页记录失效/丢失”，提示需要回退到全量扫描等恢复策略。
推进方式讨论：不走 fast track，拟以新 TG 汇聚多项“共享队列”相关扩展
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 支持后结束。
Device Shared Work Queue TG 推进讨论
RISC-V International Data Center SIG 召开线上双周例会。本次会议由郭任主要分享和成员共同评审并完善 Device Shared Work Queue（DSWQ）任务组（TG）Proposal for Work 文档，围绕“为何需要 TG、要做哪些规范工作、如何证明可行（PoC）以及如何组织生态协作”等关键点展开讨论。来自字节跳动、中兴通讯以及 RISC-V International 的多位代表参与交流，包括 Rafael Sene、Isaac Chute 等。
从“共享队列”出发：DSWQ 为什么成为数据中心未来技术方向？
郭任在文档讲解中首先明确 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 形成系统化规范与配套生态。
“现有扩展为何不够”：ISA 与 IOMMU 两侧缺口同时存在
在“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 场景下的优势无法充分释放。
TG 目标拆解：三项扩展 + 一揽子生态/PoC 与测试计划
在“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 等。
社区关键建议：PoC 需要明确写入提案，测试与发行版合作要可落地
会议讨论中，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 正在把“共享队列 + 虚拟化 + 热迁移”这一云关键路径能力，从点状提案推进到任务组化、规范化与可验证的工程路线图阶段。
—— 完 ——
