gem5 仿真软件技术调研报告（v1.2）：事件驱动内核、模型谱系与 RISC-V 支持边界

摘要

• gem5 是模块化的系统级仿真平台，仓库以「Python 配置层 + C++ 模型层」双语言装配：配置脚本在 Python 中构建对象树，模型以 SimObject 双声明注册，构建期由 SCons 驱动生成 C++ 参数结构与绑定，二进制自身内嵌 Python 解释器 [S01][S13]。
• 执行内核是共享同一 tick 轴的确定性事件队列：模型通过 schedule/deschedule 挂接事件，主循环以 serviceOne() 弹出事件、推进 curTick 并调用 process()，直到退出事件收束；多事件队列模式用 GlobalSyncEvent 按 simQuantum 量化同步以保持确定性 [S03][S04][S05]。
• CPU 侧提供五条模型路线——Atomic/Timing SimpleCPU、Minor 顺序流水线、O3 乱序流水线与 KVM 原生执行；存储侧提供经典缓存与 Ruby/SLICC 两套体系，配合 MemCtrl + DRAMInterface 的介质抽象与可选 DRAMSim2/3 等外部模型 [S14][S15][S16][S17][S18][S19][S20]。
• 可复现能力由统计与检查点两块构成：Stats::Group 统计框架以事件方式转储 stats.txt 等格式，Serializable 体系逆序序列化全部对象生成 m5.cpt，m5 伪指令（workbegin/workend 等）支撑 SimPoint 式负载切分与检查点触发 [S21][S22][S06]。
• RISC-V 支持面在 v25.1.0.1 上完整可用：五个 CPU 绑定类、RVV 默认启用（VLEN 256）、MHSU 特权档联动 H 扩展、riscvmatched 平台基于 Minor 建模 U74；v1.1 以来两轮更新补上社区现状（RISC-V KVM 已于 2026-08-14 合入 develop）、双轨发展史（2015 年桩文件至 2026 年 KVM 合入的五阶段路线）与 RISC-V 64 模块地图及分档切入建议；中断面仍未建模 AIA，指令覆盖度与性能保真度须以实测为准 [S23][S24][S28][S33][S35][S37]。

背景与现状

gem5 的定位是「模块化的计算机系统体系结构研究平台，覆盖系统级架构与处理器微架构」，主要用于评估新硬件设计、系统软件改动与编译期/运行期优化 [S01]。它由学术界发起、由社区在 GitHub 协作维护，官网为 gem5.org；截至 v20.0+ 论文成稿时，贡献者已超过 250 人、提交超过 7500 次 [S29]，2026 年的复现性工作论文则记录了 1600+ 个 fork 与 2000+ 个预打包制品的资源库规模 [S30]。这决定了它的使用方式：不是装在系统里的一件工具，而是一个需要固定版本、自行构建的研究基础设施。

工程形态上，gem5 的构建入口是 SCons：官方命令为 scons build/ALL/gem5.opt，构建目录名（如 ALL、RISCV、X86_MESI_Two_Level）决定使用 build_opts/ 下的同名预设文件 [S01][S07]。依赖包括 g++ 或 clang、Python、SCons、zlib、m4，以及用于 trace 抓取回放的 protobuf [S01]。支持的 ISA 名单在主仓 README 中列出：ARM、NULL、MIPS、POWER、RISCV、SPARC、X86 [S01]。仓库对 develop 分支运行每日、每周与编译器三类 CI，质量滚动依靠这批测试保障 [S01]。

版本节奏为一年两个主版本，2025 年发布了 25.0 与 25.1，其中 25.1 由 649 个提交、291 个合并 PR、58 位贡献者构成，随后有 25.1.0.1 热修复 [S02]。近三个版本的演进主线可以读出两条：一是通用微架构模型的持续加密（Neoverse V2 核模型、gshare 分支预测器、乱序核分布式指令队列 IQUnit、解耦前端与取指导向预取器 FDP 等）；二是 RISC-V 面的持续加厚（25.0 引入 H 扩展与 hypercall 退出机制，24.x 补齐 RVV 指令与 RiscvBoard 生态，25.1 增加 vandn/vwsll/vror/vcompress 等向量指令并修复 RISC-V 检查点与 rseq 兼容问题）[S02]。

图 1：gem5 五层装配总览。来源：按 README [S01]、src/SConscript [S07]、src/python/m5/simulate.py [S11] 与 pybind11 绑定源码 [S12] 整理；数据口径：commit c8222cc6 行号级核对。

见图 1。它把一次运行切成五层：入口与配置层回答「谁来描述系统」，语言桥回答「Python 对象如何变成 C++ 对象」，事件内核回答「时间如何推进」，模型层回答「CPU、存储与外设怎么算」，产出层回答「结果如何落盘」。读图时注意两条贯穿线：其一，SimObject 是贯穿配置层、语言桥与模型层的同一概念，只是在不同阶段有不同的存在形式；其二，事件队列是唯一的时间引擎，统计转储、CPU 周期推进与外设响应都以事件身份排在同一个队列上，这正是后文机制分析的共同基础。

社区与 RISC-V 64 活跃度（v1.1 更新，实测 2026-10-13）

本节基于对 gem5 主仓的 2026-10-13 单日实测，口径与限制见附录 C [S33]。社区基本面上，主仓星标 2,867、复刻 1,996、贡献者约 508、开放议题 216；默认分支为 stable，开发主线在 develop [S33]。治理沿袭精英制：任何人只要能够展示尊重即可贡献，角色从用户到贡献者再到维护者，维护者由提名并经理事委员会投票产生，日常决策走「惰性共识」 [S32]；贡献流程是在 Jira 或 GitHub 议题中选择任务、先留言请教、再认领、最后发拉取请求 [S31]。

把镜头切到 RISC-V 64：近 12 个月（2025-10 至 2026-10），develop 分支上改动 src/arch/riscv 的提交共 87 笔，占全仓 1,133 笔提交的约 7.7%（作者日口径，见附录 C），月度峰值出现在 2026-03（17 笔）与 2026-04（14 笔） [S33][S37]。按提交署名聚合，活跃贡献者为 Selim Sandal（13）、Erin Le（两种署名合计 10）、Saúl 与 amatabsc（各 9）等，头部三人贡献了约三分之一强的提交 [S33]。自 v25.1.0.1 热修复（2026-04-21）以来，标题含 RISC-V 的已合并拉取请求有 45 个，另有 38 个开放议题与 23 个开放拉取请求 [S33]。

这段时间最值得记录的变化是 RISC-V KVM 支持落地：拉取请求 #3053 于 2026-08-14 合入 develop（26 个文件、新增 2,342 行，作者 selimsandal），在 src/arch/riscv/kvm/ 下新增 RiscvKvmCPU（RiscvKvmCPU.py、riscv_cpu.cc/hh 等五个文件），并附全系统示例配置 riscv-ubuntu-run-with-kvm.py [S35][S33]。这与 v1.0 基于 v25.1.0.1 快照给出的「无 RISC-V KVM」边界形成时间差——快照结论保持不变，但 develop 已把这块短板排上日程并完成合入。同期推进还包括：Sv48/Sv57 虚拟内存体系（#3086）、BF16 标量与向量支持（#3273）、基于 profile 的扩展配置报告（#3320），以及持续的 RVV 重构与修复（vcompress、归约类、滑移类指令）与 mcycle/minstret 写入支持等 [S33]。配套生态上，gem5-resources 已提供 RISC-V 全系统资源：riscv-fs（OpenSBI 引导与 Ubuntu 22.04/24.04 镜像）、riscv-fs-alt（busybox 与无盘启动链）以及 GAPBS、NPB 等基准的 RISC-V 构建脚本 [S34]。

图 5：gem5 RISC-V 近 12 个月提交节奏与活跃作者（develop 分支）。来源：GitHub REST API 实测 [S33]；数据口径：path=src/arch/riscv、since=2025-10-01，作者按提交署名聚合（同一人不同署名分别标注），2026-10 为不完整月（截至 10-13）。

见图 5。左图给出提交节奏：2026 年 3–4 月是 KVM 系列与 RVV 补全的密集推进期，此后保持每月三到八笔的稳定节奏，说明 RISC-V 已是有固定人马维护的常设工作面，而非偶发热点；右图示出作者分布，头部贡献者与上游评审圈（拉取请求 #3053 中致谢的 @erin-le、@BobbyRBruce、@powerjg）高度重合，说明「作者—评审」核心圈在当前阶段对 RISC-V 方向起决定性作用。对计划入场的读者，这提示了一个具体机会：KVM 刚合入 develop，稳定化与测试覆盖正是接下来数月最需要社区力量的方向。

双轨发展史：从 2015 年桩文件到 2026 年 KVM（v1.2 更新）

本节回答两个问题：gem5 主仓十余年的节奏是什么样，RISC-V 64 子系统在其中如何生长。数据口径为 develop 分支完整 git 历史的「作者日期」统计——全仓 24,600 笔、RISC-V 路径 851 笔（2015–2026-10），里程碑取对应主题的首个提交，口径与限制见附录 C [S37]。

主仓层面的曲线本身就是社区编年史：完整历史可追溯到 2003 年（仓库导入了完整的血统史），2017 年之后进入稳定扩张——2018 年破千、2019 年 1,274 笔、2020 年 1,636 笔、2021 年以 2,128 笔达到全史峰值，随后稳定在每年 1,100–1,400 笔的高位，2026 年至 10 月中已积累 863 笔 [S37]。版本节奏自 2020 年起固定为一年两个主版本（v20.0 至 v25.1 保持半年间隔），2026-04 新增 v25.1.0.1 热修复通道 [S37]。

RISC-V 子系统走出一条从摇椅到引擎的曲线（图 7）。2015–2016 播种期：2015-07-20 目录以桩文件形式出现（随系统调用重构补丁附带 faults.cc），真正的起点是 2016-11-30 Alec Roelke 提交的 [Patch 1/5] RV64I 系列——同一天 RV64M、RV64A、RV64FD 与 pagetable.cc、interrupts.cc 一并落地，基本盘一次成型 [S37]。2017–2020 基础成型期：RV64C 压缩扩展（2017-06）、页表构建迁入架构层（2017-12）、m5 伪指令（2020-02）与 FS 模式完善（2020-03），2020 年年度提交 84 笔，平台开始具备全系统研究的能力 [S37]。2021–2022 平台化期：CLINT/PLIC 设备与 PMP（2021-02）、FS workload 正规化（2021-03）、riscvmatched 预置板进入 stdlib（2022-09）、RV32 ABI（2022-11）；2021 年冲到 157 笔的全史峰值，随后 2022 年回落到 45 笔——这不是衰退而是特征：平台底座已经稳定，改动转向按需提交 [S37]。2023–2024 指令与生态扩张期：RVV 1.0 指令系列从 2023-02 起步、随 v23.1（2023-12-28）发布成型，位操作扩展（2023-05）、semihosting（2024-04）、Zc 与 H 扩展系列（2024-07）接连落地；两年提交 263 笔，年度活跃作者从 24 人增至 33 人——子系统的「人口基数」在这两年翻倍 [S37]。2025–2026 成熟与快进期：H 扩展随 v25.0（2025-06-18）交付，PMP 检查点与 KVM 系列于 2026-03 并行启动，v25.1.0.1 热修（2026-04-21）、Sv48/Sv57（2026-05）、BF16 与 RISC-V KVM 合入（2026-08）接连发生；2026 年至 10 月中 68 笔，节奏稳定在每月三到八笔 [S37][S35]。

把两轨叠加（图 6）可以读出三个结构性事实。其一，RISC-V 的每次能力跃迁都紧跟主版本的发布窗口：RVV 1.0 对准 v23.1、H 扩展对准 v25.0、KVM 瞄准下一个发布窗口——贡献者的工作节奏与半年发布钟摆同步，是最值得利用的制度节拍 [S02][S37]。其二，子系统的占比曲线（图 7）自 2023 年起稳定在 7% 至 10% 区间，2024 年达 10.1% 的历史峰值，2026 年即使在全仓节奏放缓的背景下仍占 7.9%——它已是 gem5 内部的稳定权重板块，而非兴趣小组 [S37]。其三，人是最稀缺的资源：全史 656 位贡献者中，RISC-V 路径的头部三人（Gabe Black 213 笔、Roger Chang 75 笔、Alec Roelke 48 笔）贡献了约四成提交，近两年活跃作者维持在 21 至 22 人——「有固定人马维护的常设工作面」这个判断在历史数据层面得到确认 [S37][S36]。

（*2026 为截至 10-13 的不完整年度；口径为作者日期、含合并提交 [S37]。）

图 6：gem5 双轨时间线（2015–2026）。来源：develop 完整 git 历史与主要 tag 提交日期实测 [S37]；数据口径：作者日期，发布点取 tag 提交日期，底色为五阶段划分。

见图 6。上轨是主版本发布节奏，下轨是 RISC-V 子系统的十四个里程碑，底色区分五个阶段。读图要点：其一，播种与成型极不对称——2016 年一天之内落地的四个基础补丁之后，体系用四年补齐 MMU、设备与全系统能力；其二，2021 年之后节奏明显「靠发布钟摆走」，RVV、H 扩展、KVM 三个大事件分别紧贴 v23.1、v25.0 与下一个发布窗口；其三，最近 12 个月的节点密度为历史最高（PMP 检查点、KVM、Sv48/57、BF16 集中在 2026 年 3 至 8 月），对计划入场者是少见的窗口期。

图 7：RISC-V 子系统成长曲线（2016–2026）。来源：同前 [S37]；数据口径：作者日期，柱为年度提交数（笔，左轴），线为占全仓年度比例（%，右轴）。

见图 7。柱线组合回答「子系统长大了多少」：2016–2020 是爬坡段（11 笔到 84 笔），2021 年 157 笔为全史峰值，2022 年回落后 2023–2024 站上 130 笔级平台并录得 10.1% 的占比峰值；2025 年的回落与主仓整体节奏放缓同步，2026 年以 7.9% 的占比显示权重仍在。折线的读法更重要：占比长期上台阶（从 3% 级到 7–10% 级）说明子系统增速持续快于主仓——按这个趋势，它容得下一个长期投入的外围贡献者。

RISC-V 64 模块地图与切入建议（v1.2 更新）

上一节给出时间维度，本节给出空间维度：851 笔历史提交在子系统内部的分布，以及一个外围贡献者应该从哪里下铲。图 8 把 src/arch/riscv 及其外围画成六块承载体，括号内为该模块集合命中的提交数（同一提交可触及多块，仅用于热度比较）[S37]。

图 8：RISC-V 64 模块地图与三档切入建议。来源：模块划分按 v25.1.0.1 源码树 [S24][S26][S28]，提交热度按 develop 全史路径统计 [S37]；数据口径：作者日期、含合并提交。

见图 8。左侧六块从指令（①）、架构状态（②）、地址保护（③）、运行模式（④）到平台设备（⑤）与前沿快进（⑥）是完整的承载体；右侧三档建议按「摩擦从低到高」排序，并用虚线连回对应模块。三条读图要点：其一，历史热度最高的不是最先想到的指令层，而是架构状态与异常（127 笔）——CSR、异常与中断语义是修复最长尾的地方，也是建立信任的路径之一；其二，地址与保护（页表、TLB 与 PMP 合计 105 笔）与指令层（154 笔）构成中间层，历史证明这里的修复评审路径成熟、合并率高；其三，前沿区的 KVM 只有 13 笔历史（2026-03 才诞生），是典型的早期红利区——任何测试与文档补强都是增量价值 [S35][S37]。

落到这位读者的具体建议：依托系统软件与性能工程的背景，从一档的 insts/ 小修复或 dev/riscv 设备修复开始建立首批评审记录（历史上一档类改动正是社区常见的「第一笔 PR」形态）；第二笔起进入二档，优先挑选与工作经验直接相通的 pagetable/TLB 或 PMP/PMA；三档留待第一个季度里程碑达成后，优先考虑 KVM 稳定化——它刚合入、测试缺口大、维护者活跃，是「新窗口加老大难」的组合 [S35][S37]。完整的社区选择与 90 天节奏设计见配套的《开源社区调研报告》 [S36]。

零基础上手路径（v1.1 增补）

面向 gem5 零基础但具备系统编程背景的读者，最短上手路径由三步组成。第一步，构建最小可用二进制：按 README 安装依赖（g++ 或 clang、Python、SCons、zlib、m4，trace 功能需要 protobuf），执行 scons build/RISCV/gem5.opt 构建仅含 RISC-V 的优化版（全 ISA 版为 scons build/ALL/gem5.opt） [S01]。第二步，跑通第一个系统调用模拟实验：./build/RISCV/gem5.opt configs/example/gem5_library/riscvmatched-hello.py，该示例在预置的 riscvmatched 平台上以 SE 模式运行 hello 程序，脚本头部注明用法 [S25]；随后把目标换成 RVV 微基准（./build/RISCV/gem5.opt configs/example/gem5_library/riscv-rvv-example.py -c 1 -v 256 -e 64 rvv-matmul），体会向量扩展参数的配置方式 [S25]。第三步，进入全系统：./build/RISCV/gem5.opt configs/example/gem5_library/riscvmatched-fs.py 启动 Ubuntu 24.04 镜像，观察内核启动过程 [S25]。每一步产出的 m5out/ 目录里有 config.ini 配置快照与 stats.txt 统计文件，是验证实验是否按预期运行的直接依据 [S11][S21]。

学习材料沿两条线推进：官方「Learning gem5」教程及其配套源码（本仓库 src/learning_gem5，本报告 3.1 节引用的 HelloObject 样例即出自其中 [S01][S10]），配合本报告 3.1 至 3.2 节对照阅读装配与内核机制。走通三步之后，按贡献指南的「留言—认领—拉取请求」流程从文档与测试类议题起步，模块切入点见上一节的模块地图 [S31]；社区选择与节奏设计的完整方案见配套的《开源社区调研报告》 [S36]。

技术详解：以事件驱动内核为中心的仿真平台

3.1 双语言装配置：SimObject 声明、构建期代码生成与五阶段实例化

gem5 的一次仿真分为三段：配置脚本执行、实例化与仿真循环。第一段由二进制内的 Python 解释器完成——src/sim/main.cc 在 81 行调用 py::scoped_interpreter 拉起解释器，84 行安装自定义导入器 importer.attr("install")()（src/python/importer.py:83），87 行导入 m5 并调用 m5.main()（入口在 src/python/m5/main.py:388，输出目录默认 m5out 于 104 行）。也就是说，gem5 二进制本质上是一个「带 C++ 模型库的 Python 解释器」，这是理解全部装配机制的前提 [S13]。

构建系统承担第二层装配。SCons 构建目录名决定预设：SConstruct:220 定义 buildopts_dir，964 行把 build/RISCV 映射到 build_opts/RISCV，该文件仅五行——RUBY=y、PROTOCOL="MI_example"、RUBY_PROTOCOL_MI_example=y、BUILD_ISA=y、USE_RISCV_ISA=y（1-5 行）[S07]。因此「构建哪个 ISA、用哪套一致性协议」在构建期就固化进二进制，这也是 gem5 同时只支持单一 Ruby 协议的原因。

SimObject 的双声明是装配置的核心：每个模型在 Python 侧声明一次（名称、C++ 头文件、参数），构建期自动生成 C++ 参数结构与 Python 绑定 [S07][S10]。教学样例 src/learning_gem5/part2/SConscript:30-31 展示了声明语法：

SimObject('SimpleObject.py', sim_objects=['SimpleObject'])
SimObject('HelloObject.py', sim_objects=['HelloObject', 'GoodbyeObject'])

对应的 Python 类在 HelloObject.py:31 声明 type、cxx_header、cxx_class 与参数（如 time_to_wait = Param.Latency(...)、number_of_fires = Param.Int(1, ...)）[S10]。构建类 SimObject(PySource) 定义在 src/SConscript:142，它对每个 sim_objects 条目生成三类产物：params/<Name>.hh C++ 参数结构（生成器 build_tools/sim_object_param_struct_hh.py，读取类属性 _params.local [S08]）、python/_m5/param_<Name>.cc 绑定、以及可选的 cxx_config 序列化；Python 源文件本身则由 build_tools/marshal.py 序列化后以 <source>.py.cc 形式嵌入二进制（src/SConscript:100 起的 PySource 类，动作名为 EMBED PY）[S07]。

C++ 与 Python 的运行时桥接由 pybind11 实现：src/python/pybind11/ 下按职能拆分模块，event.cc:108 用 m.def("simulate", &simulate) 暴露仿真循环，core.cc:338 暴露 serializeAll，event.cc:137 暴露 GlobalSimLoopExitEvent 及其 getCause/getCode/getPayload/getHypercallId 四个访问器 [S12]。Python 侧 m5/SimObject.py 的元类 MetaSimObject（130 行）负责参数赋值校验与类型检查，createCCObject()（1321 行）在实例化时创建对应的 C++ 对象 [S09]。

实例化由 m5.instantiate()（src/python/m5/simulate.py:220）按固定次序执行：_fix_all_objects(root)（77 行）预处理对象树，_dump_configs()（95 行）输出 config.ini 快照，_create_cpp_objects()（147 行）完成五阶段实例化，_dump_configs_post_cpp()（201 行）补输出 [S11]。其中五阶段实例化按如下顺序执行：

① 为对象树每个后代调用 createCCObject() 创建 C++ 对象； ② 再遍历一次调用 connectPorts() 连接端口拓扑； ③ 第三遍调用 init() 完成对象初始化； ④ 先 stats._bindStatHierarchy(root) 绑定统计层级，再调用 regStats() 注册统计，之后 stats.enable()； ⑤ 调用 regProbePoints() 与 regProbeListeners() 注册探针，再按是否有检查点选择 loadState(ckpt) 或 initState()。

五遍遍历而不是一遍完成，原因是各类初始化存在依赖方向：端口必须在全部对象都存在后才能连接；统计与探针必须在对象图完整且 init() 之后注册，否则分组树会缺枝；检查点恢复必须发生在统计启用之后、仿真开始之前。参数系统本身也在演进：25.0 新增 OptionalParam 与 DictParam 两种参数类型，前者用于表达「未设置」而不借用魔法默认值，后者让字典成为一等参数 [S02]。

失败边界方面有三类可定位的症状：构建期忘列 sim_objects 会直接报 SimObject(...) must list c++ sim_objects or enums（src/SConscript:152）；实例化抽象类会触发 fatal("Cannot instantiate an abstract SimObject ...")（SimObject.py:1323）；重复实例化会报 m5.instantiate() called twice.。验证条件方面，可以执行 scons build/ALL/gem5.opt 构建全部 ISA 版本，再以 ls build/ALL/params | head 检查参数头生成物，用 grep -n "sim_objects" src/learning_gem5/part2/SConscript 复核声明与产物的对应关系。成本与权衡在于：以 Python 声明作为唯一事实源换来了参数不重编译即可调整的便利，代价是构建期代码生成链更长（marshal 内嵌、参数结构、绑定三套生成器），改 C++ 头文件与改声明都会触发较重的重编译，这是使用时需要预期的开销。

3.2 事件驱动内核与仿真生命周期

gem5 的时间模型是单 tick 域上的离散事件队列（src/sim/eventq.hh）。队列按「链表之链表」（bin）组织，事件类型继承 Event（254 行）并实现 process()；调度接口是 schedule()/deschedule()（1101 行起多个重载）。事件优先级决定同一 tick 内的执行次序，常数从 -100 到 100 分布，关键档位如下表 [S04]。

队列推进的单步逻辑在 EventQueue::serviceOne()（src/sim/eventq.cc:224）中，核心片段如下：

Effect *event = head;
event->flags.clear(Event::Scheduled);
...
if (!event->squashed()) {
    // forward current cycle to the time when this event occurs.
    setCurTick(event->when());
    event->process();
    if (event->isExitEvent()) {
        return event;
    }
} else {
    event->flags.clear(Event::Squashed);
}

可以看到三个要点：被 squash 的事件直接跳过；正常事件先把全局时钟推进到事件触发时刻再执行；执行后若该事件是退出事件则返回给调用者终止循环。全局循环在 src/sim/simulate.cc：simulate()（191 行）由 Python 侧 m5.simulate()（simulate.py:277 经 _m5_event.simulate）调用，随后进入 doSimLoop()（293 行）。主循环每一轮的次序固定：

① 若判定存在异步信号，先处理统计转储、IO 轮询、退出、异常与 hypercall 五类分支（308-337 行）； ② 调用 eventq->serviceOne() 弹出并执行一个事件（339 行）； ③ 若该事件为退出事件，带着它返回 Python 终止本线程循环（339-342 行）； ④ 否则回到第 ① 步，此时时间轴已推进到事件触发时刻。

循环内有两个断言守住时间单调性：队列非空，且 curTick() <= eventq->nextTick()（「event scheduled in the past」）。

仿真生命周期中的另一条线是退出语义与统计转储。退出通过 exitSimLoop() 生成 SimLoopExitEvent，其字符串原因由 src/python/gem5/simulate/exit_event.py:30 的 ExitEvent 枚举归类，translate_exit_status 建立字符串映射：m5_exit instruction encountered 归为 EXIT，simulate() limit reached 归为 MAX_TICK，checkpoint 归为 CHECKPOINT，user interrupt received 归为用户中断。25.0 起退出事件改走 hypercall 通道，src/python/gem5/simulate/exit_handler.py:86 的 ExitHandler 基类按 hypercall_num 注册子类（如 CheckpointExitHandler 为 7、WorkBeginExitHandler 为 4）[S02]。统计转储同样以事件身份排队：src/sim/stat_control.cc:73 的 StatEvent 以 Stat_Event_Pri 入队，schedStatEvent()（106 行）刻意加上 simQuantum 以确保转储发生在跨队列同步之后，periodicStatDump()（118 行）实现周期转储。

多事件队列模式用于并行加速：当 numMainEventQueues > 1 时，simulate.cc:226-235 创建 GlobalSyncEvent 量化事件（周期为 simQuantum），主线程与从属线程（SimulatorThreads，68 行）各自跑 doSimLoop 并在屏障处对齐；若未指定量子则直接 fatal 报 Quantum for multi-eventq simulation not specified。跨线程插入事件走 asyncInsert/handleAsyncInsertions()（eventq.cc:458）延迟合并，以保证确定性。

失效边界与验证：在 m5.instantiate() 之前调用 m5.simulate() 会报 m5.instantiate() must be called before m5.simulate().；把事件调度到过去的 tick 会命中前述断言；退出原因字符串若拼写不精确（如伪指令触发的检查点要求原因恰为 checkpoint）会落入 EXIT 之外的归类。验证办法是可复现的：执行 ./build/RISCV/gem5.opt configs/example/gem5_library/riscvmatched-fs.py 之类的脚本后检查 stdout 中的退出原因、m5out/stats.txt 的转储时刻，并以 grep -n "Sim_Exit_Pri\|Stat_Event_Pri" src/sim/eventq.hh 复核优先级表。成本与权衡方面：单队列串行保证逐 tick 确定性，代价是仿真吞吐受限；多队列并行按量子同步提升吞吐，但同步点粒度（quantum）过大会引入跨队列事件乱序风险，过小则同步开销吃掉收益，这是并行仿真的主要调参点。

图 2：gem5 一次仿真的生命周期。来源：按 src/sim/simulate.cc [S03]、src/sim/eventq.cc [S05]、src/python/m5/simulate.py [S11] 与 src/sim/pseudo_inst.cc [S06] 整理；数据口径：commit c8222cc6 行号级核对。

见图 2。流程从二进制拉起 Python 开始，到退出后再经过检查点与统计收尾结束；图中中段的三件套——五阶段实例化、doSimLoop 单步、退出事件分派——是理解一切「为什么这样配置」的锚点。右侧两张注记卡分别回答两个常见疑问：事件为什么要有优先级（同一 tick 内的次序语义），以及多核并行仿真的确定性从何而来（量子同步）。

3.3 CPU 模型谱系与两种执行模式

CPU 模型层由 BaseCPU 统一挂接，简单核族共享 BaseSimpleCPU（src/cpu/simple/base.hh:83），五条路线按建模精度递增排列：Atomic、Timing、Minor、O3 与 KVM。AtomicSimpleCPU（atomic.hh:53）的推进逻辑在 atomic.cc:611 的 tick()：每个时钟周期最多执行 width 条指令，取指走 translateAtomic 功能翻译，执行由 curStaticInst->execute() 完成；若参数开启 simulate_inst_stalls/simulate_data_stalls，则把访存延迟与系统调用重试等停顿累加到 latency，不足一个时钟周期按 clockPeriod() 取整，最终 reschedule(tickEvent, curTick() + latency, true) 安排下一次触发。这意味着 Atomic 模式的访存是「瞬时的功能访问 + 可选的固定延迟修正」，不建模访存并行与乱序，适合快速前进与功能验证。

for (int i = 0; i < width || locked; ++i) {
    baseStats.numCycles++;
    ...
    fault = thread->mmu->translateAtomic(ifetch_req, thread->getTC(),
                                         BaseMMU::Execute);
    ...
    fault = curStaticInst->execute(&t_info, traceData);
}
if (latency < clockPeriod())
    latency = clockPeriod();
if (_status != Idle)
    reschedule(tickEvent, curTick() + latency, true);

把这条链拉直，Atomic 模式一条指令的完整次序是：

① setupFetchRequest(ifetch_req) 准备取指请求并绑定任务标识； ② translateAtomic 完成取指地址翻译，取回指令字节； ③ curStaticInst->execute() 执行并推进 PC； ④ 若开启 simulate_inst_stalls/simulate_data_stalls，把缓存访问延迟与服务调用重试转为停顿累计； ⑤ reschedule(tickEvent, curTick() + latency, true) 安排下一次 tick 触发。

TimingSimpleCPU（timing.hh:53）把访存改为经时序端口接口完成：一条指令的取指或数据访问发出后，CPU 停等响应事件到达才继续，拆分访问由 SplitMainSenderState 状态对象跟踪（timing.hh:55-75 注释），翻译过程也可异步完成。它比 Atomic 慢但给出内存延迟敏感的第一近似。MinorCPU（src/cpu/minor/cpu.hh:84）是顺序流水线模型：fetch1/fetch2/decode/execute 各级带缓冲与背压，功能单元（FU）可替换；gem5 自带的 U74 平台就是按此路线建模——riscvmatched_core.py:109 的 U74CPU 继承 RiscvMinorCPU，并配套 8 个功能单元类（Int/IntMul/IntDiv/FloatSimd/Pred/MemRead/MemWrite/Misc，45-75 行）、FU 池（79 行）与专属分支预测器 U74BP（93 行），对应 SiFive U74 核的公开微架构参数。

O3CPU（o3/cpu.hh:96）是乱序流水线：类注释明确「fetch through commit 每一级都在本类内，含级间时间缓冲」，源码目录里 fetch.cc、rename.cc、iew.cc、commit.cc、rob.hh、scoreboard 等文件对应五级流水的部件拆分；它用于研究重排序、发射宽度、ROB 容量等乱序微架构问题。KVM 路线（kvm/base.hh:87）把 guest 交由宿主 CPU 原生执行，类注释规定架构相关实现只需覆写 updateKvmState()/updateThreadContext() 同步状态即可接入；其强项是以接近原生的速度运行真实软件栈并观察外设交互，弱项是微架构不可观测。一个必须记录的边界是：仓库中 KVM 仅有 Arm 与 x86 两套实现（src/arch/arm/kvm、src/arch/x86/kvm），v25.1.0.1 快照中没有 RISC-V 目录 [S17]；v1.1 更新：develop 分支已于 2026-08-14 合入 RISC-V KVM（src/arch/riscv/kvm/，拉取请求 #3053），细节见背景与现状的社区更新 [S35]。

执行模式分 SE（系统调用模拟）与 FS（全系统）两类：SE 模式用 src/sim/process.cc 的 Process 加载用户态二进制并代答系统调用，启动快、无需镜像；FS 模式运行内核与设备模型，RISC-V 侧对应 RiscvSystem 与 RiscvBootloaderKernelWorkload（RiscvFsWorkload.py:83），支持指定 bootloader 文件与装载地址（默认 0x80000000，91-92 行）以及新增的 initrd 参数 [S26][S02]。两种模式可在检查点处切换 CPU 模型：switchcpu 伪指令触发 exitSimLoop("switchcpu")（pseudo_inst.cc:471-474），配合 --restore 类流程实现「先 Atomic 快进、再 O3 精细测量」的实验设计。

RISC-V 侧五种 CPU 绑定类齐备（src/arch/riscv/RiscvCPU.py:44-60：Atomic、NonCaching、Timing、O3、Minor），配置侧常见两条路线：RVV 示例用 RiscvO3CPU 并设置 VLEN/ELEN（riscv-rvv-example.py:66-70），U74 平台用 Minor 并对 FS 4 核、SE 1 核取不同配置（riscvmatched_processor.py:50-55）。

失效边界与验证：Atomic 模式不建模乱序与访存并行，其周期数不宜作为性能依据；KVM 无 RISC-V 实现，选择它处理 RISC-V 目标会直接找不到类；Minor/O3 的 FU 与 ROB 参数配置错误会在构建期（Python 参数类型检查）或运行期断言暴露。验证命令：scons build/RISCV/gem5.opt 构建 RISC-V 二进制后，运行 ./build/RISCV/gem5.opt configs/example/gem5_library/riscv-rvv-example.py -c 1 -v 256 -e 64 rvv-matmul 观察 RVV 负载执行与 m5out/stats.txt 中的周期数口径。成本与权衡是一条连续谱：从左到右精度升高、速度下降；Atomic 到 KVM 的周期跨度可达数个量级，选型应匹配实验目标而非默认追求「最精确」。

图 3：gem5 CPU 模型谱系与 RISC-V 实例。来源：按 src/cpu/simple/atomic.cc [S14]、src/cpu/o3/cpu.hh [S15]、src/cpu/minor/cpu.hh [S16]、src/cpu/kvm/base.hh [S17] 与 riscvmatched 预置平台源码 [S28] 整理；数据口径：commit c8222cc6 行号级核对。

见图 3。上半部分是五条模型路线的精度-速度谱，箭头方向提示「越往下动越慢、越贵、越像真实机器」；中间两个绿色框给出 RISC-V 的具体落点：五个绑定类全可用，U74 平台是 Minor 加定制 FU 与分支预测器的组合；底部是 SE/FS 两种执行模式。读图要点：选型从实验问题出发——问「功能对不对」用 Atomic，问「内存延迟趋势」用 Timing，问「顺序核瓶颈」用 Minor，问「乱序与前端行为」用 O3，问「真实软件栈速度」才考虑 KVM。

3.4 存储系统：经典缓存与 Ruby/SLICC 双体系

存储侧的组装基于端口与包模型：src/mem/port.hh 定义请求/响应端口协议，packet.hh/request.hh 承载访问语义，互联用 CoherentXBar（coherent_xbar.hh:70）或 noncoherent_xbar，多通道内存交错在交叉开关处完成。缓存有两条互斥路线。第一条是经典缓存：BaseCache（src/mem/cache/base.hh:103）继承 ClockedObject，带标签/数据阵列、MSHR 与写缓冲等结构，缓存层次由配置脚本组装（stdlib 提供 L1I/L1D/L2/MMU cache 组件，riscvmatched 平台即用经典层次 [S28]），适合以延迟与带宽参数近似缓存行为。

第二条是 Ruby：完整的时序一致性模型，缓存控制器是一族由 SLICC 语言编译出的状态机。SLICC 编译器位于 src/mem/slicc/（含 parser.py 等），协议源文件以 .sm 结尾，用 machine() 块声明控制器与资源。以 MESI_Two_Level 的 L1 为例（MESI_Two_Level-L1cache.sm:41）：

machine(MachineType:L1Cache, "MESI Directory L1 Cache CMP")
 : Sequencer * sequencer;
   CacheMemory * L1Icache;
   CacheMemory * L1Dcache;
   Cycles l1_request_latency := 2;
   Cycles l1_response_latency := 2;
   Cycles to_l2_latency := 1;

该块声明了 L1 控制器的队列接口、缓存资源与时钟级延迟参数，后续同文件中的状态转移表描述每个事件（更常见的是目录控制器与缓存控制器之间的消息）在各个状态下如何更新与响应。Ruby 总控是 RubySystem（src/mem/ruby/system/RubySystem.hh:64），网络默认 Garnet 可换成简单互连，协议可选集见下表（取自 build_opts/ALL 的协议清单 [S07]）。

访问路径的推进顺序因路线而异。经典路线的次序是：

① CPU 端口发出 Packet（含请求类型与地址范围）； ② 经交叉开关路由到 L1，命中即返回，未命中进入 MSHR 并继续向 L2 与内存控制器转发； ③ MemCtrl 把包翻译为 DRAM 事务并按时序排队。

Ruby 路线的次序是：

① Sequencer 把请求转交给本核 L1 控制器（SLICC 状态机）； ② 控制器按协议向目录或其他控制器发消息，经 Garnet 网络传递； ③ 目录按目录状态裁决一致性，最终向 DRAM 控制器读写数据。

两条路线的内存侧终点相同——MemCtrl（mem_ctrl.hh:246，继承 QoS 版 qos::MemCtrl）与其介质接口 MemInterface（mem_interface.hh:74）/DRAMInterface（dram_interface.hh:65）。mem_ctrl.hh 的类注释明确其设计原则：单通道控制器，「非周期可调用，而是用事件决定何时能做新裁决、何时资源可用、何时结束、何时回包」，并引用 Hansson 等人的 ISPASS 2014 论文作为模型出处；这解释了 gem5 内存系统为何整体呈事件驱动风格。外部 DRAM 模型也可接线：源码包含 DRAMSim2、DRAMSim3、DRAMSys 的包装层与 HBM 控制器（hbm_ctrl.cc）。

失效边界与验证：经典与 Ruby 是构建期二选一（RUBY=y 时经典缓存仍可用于非一致性外设路径，但核对一致性行为应以 Ruby 为准）；协议与拓扑不匹配会在构建或运行早期报错；DRAM 时序参数非物理值（如 tRCD 设置过小）不会报错，只会给出失真的周期数，需要对照 DRAM 数据手册核对。验证命令：scons build/RISCV/gem5.opt（预设即 Ruby MI_example）与 scons build/X86_MESI_Two_Level/gem5.opt 分别构建两套配置，运行后用 m5out/config.ini 核对实际生效的协议与缓存层级。成本与权衡：经典缓存配置简单、仿真快，适合以延迟带宽近似系统行为；Ruby 精确到控制器消息级、可做一致性协议研究，代价是配置复杂度与显著更慢的仿真速度，且一次构建只能带一种协议（ALL 构建可带多协议但二进制更大）。

3.5 统计、检查点与负载控制：可复现实验闭环

统计框架的骨架是 Stats::Group（src/base/stats/group.hh:92）与 Stats::Info（info.hh:79）：每个 SimObject 是一个统计组，new 出的标量/向量/直方图挂到组树上。注册发生在实例化第④步（regStats() 与 stats._bindStatHierarchy），随后 stats.enable()（src/python/m5/stats/__init__.py:312）启用采集；Python 侧 API 为 m5.stats.dump()（392 行）/m5.stats.reset()（439 行），组级转储有 dump_group()（362 行）。输出格式至少两种：文本以 text://stats.txt?desc=False 伪 URL 约定（同文件 85-86 行），HDF5 输出由 src/base/stats/hdf5.cc 的 Hdf5 类（hdf5.hh:59）实现。转储是事件化的：StatEvent（stat_control.cc:73）按 Stat_Event_Pri 入队，可在仿真中途经信号触发（doSimLoop 中的 async_statdump 分支，simulate.cc:313-315），因此「跑一半 dump 再 reset」是内核级支持的一等操作。

检查点是可复现的另一半。Python 入口 m5.checkpoint(dir)（simulate.py:401）三步走：drain() 让所有 Drainable 对象静默，memWriteback(root) 把脏数据写回，_m5_core.serializeAll(dir)（413 行）落盘。C++ 侧 SimObject::serializeAll()（src/sim/sim_object.cc:132）逆序遍历全局 simObjectList，对每个对象调用 serializeSection(cp, name) 写入检查点文件；检查点由 CheckpointOut/CheckpointIn 管理，基名固定为 m5.cpt（src/sim/serialize.cc:137）。事件本身也被序列化——Event::serialize 写入 _when/_priority/_flags（eventq.cc:265），从而保证恢复后事件时序与断点一致。恢复路径是 m5.instantiate(ckpt_dir)：实例化第⑤步走 _m5_core.getCheckpoint(ckpt_dir) + loadState(ckpt)（simulate.py:186-195），随后从检查点 tick 继续推进。25.1.0.1 热修复的第一条（#3001）恰好属于此链路：把 RISC-V 的 PMP 表加入检查点，修复此前恢复后物理内存保护状态丢失的问题 [S02]。

负载控制由 m5 伪指令体系提供，其分派表在 src/sim/pseudo_inst.hh:133 的 pseudoInstWork，按 M5OP_* 编号分发；常用指令与作用如下表 [S06]。

其中 workbegin 的检查点协同逻辑值得单列：当 System 参数 work_begin_ckpt_count 等条件满足时调用 exitSimLoop("checkpoint")，源码注释强调「退出事件的原因字符串必须恰为 checkpoint 才能触发落盘」（pseudo_inst.cc:531-535）；相关参数在 src/sim/System.py:121-143 声明（exit_on_work_items、work_item_id、work_begin_ckpt_count、work_cpus_ckpt_count）。这一机制与 BaseCPU.py:142 的 simpoint_start_insts 配合外部 SimPoint 工具，即可完成「代表性区间采样 + 检查点复用」的标准流程：先用快模跑完整 workload 找区间，再在区间起点检查点上换精细模型测量。m5 伪指令在目标程序里的客户端由 util/m5 提供，各 ISA 一套 ABI。

失效边界与验证：检查点兼容性是首要限制——跨版本恢复不保证（事件序列化注释明确旧检查点缺 Initialized 标志会失败），硬件结构改变（如缓存容量）后恢复行为未定义；统计在 stats.disable() 状态下 dump 会缺少区间数据；另外，检查点落盘前必须先完成一次全局排空（drain），有未完成内部事件的对象会把序列化推迟到排空之后，长事务外设的检查点时机应选在静默窗口 [S11]。验证命令：运行任一示例后在 m5out/ 检查 stats.txt 与 config.ini；用带 m5 伪指令的测试程序触发 checkpoint 后确认目录中出现 m5.cpt 及相关对象字符；恢复时以 m5.instantiate("m5.cpt路径") 观察 loadState 路径日志。成本与权衡：统计采集为常数级累加开销，但高频 dump 会把序列化成本引入关键路径；检查点把长实验切成可复用的片段（大幅省时），代价是单次落盘的停顿与磁盘占用，且检查点目录与二进制版本强绑定，归档实验时应把检查点、config.ini 与二进制版本一并保存。

3.6 RISC-V 支持现状评估

对 RISC-V 使用者而言，需要回答三个问题：ISA 与模型覆盖到什么程度、平台与工具链是否闭环、哪些结论只能留待实测。本节按事实、推断、未知三档给出判断，先看事实层。

图 4：gem5 RISC-V 支持现状的三档判定（v1.1 更新 KVM 动向）。来源：按 src/arch/riscv/RiscvISA.py [S23]、src/arch/riscv/RiscvCPU.py 与 insts/vector.cc [S24]、RELEASE-NOTES.md [S02]、riscvmatched 平台源码 [S28] 及 RISC-V KVM 合并记录 [S35] 整理；数据口径：commit c8222cc6 行号级核对 + 2026-10-13 develop 实测。

见图 4。三档从上到下依次是「可以逐行核对的事实」「结构性推断」与「本报告不承诺的部分」。读图要点：事实层给出的是模型与接口的存在性——有实现、有参数、有平台；推断层描述这些事实拼接出的使用方式（依赖外部工具链与资源库）；未知层提醒覆盖度与保真度这类「存在实现不等于验证通过」的问题。判读规则一句话：区分「模拟器实现了该指令/设备」与「该配置在目标负载下已实测达标」，本报告只断言前者。

事实层的完整清单如下。ISA 参数：RiscvISA.py 提供 riscv_type（RV32/RV64，95 行）、enable_rvv（默认 True，97 行）、vlen（默认 256 位，98 行）、elen（8-64，103 行）与 privilege_mode_set（M/MU/MSU/MHSU 四档，81/108 行）；get_isa_string()（142 行）按以下顺序拼接 ISA 字符串：

① 按 riscv_type 追加 rv32 或 rv64； ② 追加基础扩展 imafdc； ③ 若 enable_rvv 为真追加 v； ④ 若特权档为 MHSU 追加 h（超虚拟化扩展）； ⑤ 追加 _Zicbom/_Zicboz 等具名扩展（按参数开关）。

实现规模：isa/decoder.isa 编码 6493 行，可检索到 21 处 H 扩展指令痕迹（hlv/hsv/hfence 系）；insts/vector.cc 961 行承载 RVV 指令语义，25.1 版本新增 vandn、vwsll、vror、vrol、vcompress、vclmul/vclmulh 并修正了 pinned 寄存器与 slide 类操作 [S02][S24]。扩展覆盖还包含压缩指令（compressed.isa）、位操作（bs.isa）与 Zc 系（zcmp.isa、zcmt.isa）。平台侧：五种 CPU 绑定类齐备（RiscvCPU.py:44-60），U74 平台以 Minor 加 8 个定制 FU 与分支预测器建模（riscvmatched_core.py:109），FS 4 核、SE 1 核（riscvmatched_processor.py:50-55），板级默认 1.2GHz、L2 2MiB（riscvmatched_board.py:99/119-120）。全系统闭环：RiscvBootloaderKernelWorkload（RiscvFsWorkload.py:83）支持 bootloader 文件与装载地址（默认 0x80000000）、kernel、initrd（25.1 新增），配套 riscv-ubuntu-24.04-boot 资源（版本 2.0.0，riscvmatched-fs.py:87）可直接启动 Ubuntu 24.04。目标侧兼容：25.1 起 rseq 系统调用按 -ENOSYS 处理以适配新版 glibc [S02]。工具链：util/m5 提供 RISC-V ABI，伪指令编码为低两位象限 0x3、操作码 0x1e 的自定义指令（m5op.S 注释与宏，.long 0x0000007b | (\func << 25)），默认交叉编译器为 riscv64-unknown-linux-gnu-（abi/riscv/SConsopts:29）[S27]。边界同样明确：v25.1.0.1 快照无 RISC-V KVM 后端（develop 已于 2026-08 合入，见背景与现状的社区更新 [S35]）；中断面是 PLIC（src/dev/riscv/plic.cc）与 CLINT（clint.cc），interrupts.cc:127 只有指向 riscv-aia 仓库的注释链接，未见 APLIC/IMSIC 模型 [S17][S26]。

推断层做三个可检验的结构性判断：其一，RISC-V 支持在 gem5 中不是实验性旁支而是与 Arm/x86 并列的一等 ISA——从独立 decoder、专属 CPU 绑定类到官方 CI 覆盖，投入密度与主线一致；其二，RISC-V 全套实验可以在开源资源上闭环——用 gem5-resources 的 Ubuntu 镜像与 RVV 微基准，配合交叉编译器与 m5 伪指令，无需自建平台镜像即可开展研究 [S30]；其三，社区体量意味着查错成本可控——贡献者基础与提交历史保证了多数问题已有修复路径可循 [S29]。未知层必须诚实划界：RVV 指令覆盖度与一致性没有仓库内的套件结论，本报告未运行合规性测试，覆盖度以读者自己的实测为准；性能保真度——对具体 RISC-V 核（含 U74 之外的核）的误差，公开材料没有定量答案，需要以目标工作负载做校准实验；v26.0 开发分支已在 release-staging 阶段（写作日观察到分支 release-staging-v26-0）；develop 侧新合入的 RISC-V KVM 尚无公开的稳定性评测记录，其真实负载下的收益与缺陷需以后续版本发布后的实测为准 [S35][S33]。

失效边界与验证：把「实现存在」当「行为达标」是最大误用方式；RVV 默认启用意味着老配置脚本若显式假设无向量扩展需复核；VLEN/ELEN 非法值（非 2 的幂、越界）会在 Python 参数校验期直接抛类型错误（RiscvVectorLength/RiscvVectorElementLength 的 _check）。验证命令：构建并运行 ./build/RISCV/gem5.opt configs/example/gem5_library/riscv-rvv-example.py -c 1 -v 256 -e 64 rvv-sgemm 观察 RVV 负载；以 grep -rn "hlv\|hsv\|hfence" src/arch/riscv/isa/decoder.isa | wc -l 复核 H 指令痕迹数量；用 git -C .gem5-src rev-parse HEAD 确认研究截点。成本与权衡：RVV 默认开启、VLEN 256 是精度与速度的折中——更大 VLEN 每次上下文切换搬运更多寄存器状态，降低仿真吞吐；把 RVV 关掉可以提速功能级实验，但会改变 ISA 字符串进而影响二进制兼容性判定，切换前需评估负载是否真正用到向量指令。

总结与展望

对 gem5 的第一条判断是「装配清晰、边界诚实」：双语言装配置把「描述系统」与「实现模型」解耦，SimObject 声明是唯一事实源，构建期生成参数结构与绑定 [S07][S08]；事件驱动内核对全部模型一视同仁，时间语义（优先级、量化同步、退出原因）都有源码级约定 [S03][S04]。第二条判断是工程化程度高：一年两个主版本加热修复通道、三类滚动 CI、教学子系统与大量检查点工具的沉淀，使它适合承载长期的对照实验 [S02][S01]。从投入产出看，学习成本集中在前端装配（SimObject 与配置脚本）与版本管理上，收益则是跨 ISA、可检查点复用的统一实验框架，适合按「固定截点 + 检查点资产」的方式纳入长期实验体系。第三条判断针对 RISC-V：支持面在 v25.1.0.1 上达到「开箱可跑全系统 + RVV 可做实验」的完整度，H 扩展与 SMP 平台可用；但无 KVM 快进、无 AIA 中断模型、覆盖度与保真度需要实测校准，这三条构成当前使用的真实约束 [S23][S24][S28]。展望方向：其一，复现性基础设施仍在加厚——Packer 标准化镜像、Suites 与 MultiSim 并行实验工具已经进入社区工作流，实验归档的规范性会持续提升 [S30]；其二，微架构模型加密的路线（分布式指令队列、解耦前端、SVE2 等）会继续把 gem5 推向「近周期级」研究场景 [S02]；其三，RISC-V 支持仍在加速：KVM 支持已合入 develop（2026-08），生态维持每半年一个版本的节奏（预计延续到 v26.x），采用时建议锁定 commit、存档 config.ini/stats.txt 与检查点目录，把「哪一版二进制跑出的数据」作为实验记录的最小单位 [S35][S02]。

参考来源

• [S01] gem5 仓库 README 与许可（v25.1.0.1，commit c8222cc6）：项目定位、构建依赖、ISA 列表与 develop 分支 CI 徽章；许可见 LICENSE（BSD-3-Clause）。 README.md · LICENSE
• [S02] gem5 RELEASE-NOTES.md（同 commit）：v25.1.0.1 热修复（#3001 RISC-V PMP 检查点、#2943 Arm 构建）、v25.1 亮点与 RISC-V 小节、v25.0 hypercall 与 H 扩展、v24.x/v23.1 的 RVV 历史条目。 RELEASE-NOTES.md
• [S03] 仿真主循环与多队列并行：simulate()（:191）、doSimLoop()（:293）、量子同步（:226-235）。 src/sim/simulate.cc
• [S04] 事件与队列定义：Event（:254）、优先级常数（:182/:229/:237）、EventQueue（:615）、schedule 重载（:1101 起）。 src/sim/eventq.hh
• [S05] 队列单步执行：serviceOne()（:224）、insert()（:138）、事件序列化（:265/:274）、handleAsyncInsertions()（:458）。 src/sim/eventq.cc
• [S06] m5 伪指令：分派表 pseudoInstWork（pseudo_inst.hh:133-260）、m5checkpoint（pseudo_inst.cc:357）、workbegin（:497）、workend（:560）、switchcpu（:471）。 src/sim/pseudo_inst.cc · pseudo_inst.hh
• [S07] 构建系统：SimObject 构建类（src/SConscript:142，参数生成 163 行起，报错文案 152 行）、PySource 内嵌（:100）、build_opts 映射（SConstruct:220/:964）、build_opts/RISCV（1-5 行）与 build_opts/ALL 协议清单。 src/SConscript · 根 SConstruct · build_opts/RISCV
• [S08] C++ 参数结构生成器：读取 _params.local/_ports.local 生成 params/<Name>.hh。 build_tools/sim_object_param_struct_hh.py
• [S09] Python 侧 SimObject 元类：MetaSimObject（:130）、createCCObject()（:1321）、抽象类 fatal（:1323）、参数校验机制。 src/python/m5/SimObject.py
• [S10] SimObject 双声明教学样例：SConscript 声明（:30-31）与 HelloObject.py（:31 起参数声明）。 示例 SConscript · HelloObject.py
• [S11] Python 仿真流程：_fix_all_objects（:77）、_dump_configs（:95）、五阶段 _create_cpp_objects（:147）、instantiate（:220）、simulate（:247）、checkpoint（:401）与 serializeAll 调用（:413）。 src/python/m5/simulate.py · exit_event.py
• [S12] pybind11 绑定：simulate 导出（event.cc:108）、GlobalSimLoopExitEvent 访问器（event.cc:137）、serializeAll 导出（core.cc:338）。 src/python/pybind11/core.cc · event.cc
• [S13] 二进制入口：py::scoped_interpreter（:81）、importer.install（:84）、m5.main（:87）；m5out 默认目录（main.py:104）；importer 实现（importer.py:48/:83）。 src/sim/main.cc · src/python/importer.py
• [S14] 简单核模型：AtomicSimpleCPU（atomic.hh:53）与 tick 逻辑（atomic.cc:611）、停顿累计与重调度；TimingSimpleCPU（timing.hh:53）与拆分访问状态（:55-75）。 atomic.cc · timing.hh
• [S15] O3 乱序核：类定义与「fetch through commit」注释（:96）、五级流水部件文件。 src/cpu/o3/cpu.hh
• [S16] Minor 顺序核：类定义（:84）与流水线结构。 src/cpu/minor/cpu.hh
• [S17] KVM 路线：BaseKvmCPU（:87）与状态同步要求、KVM_KICK_SIGNAL（:55）；KVM 仅 Arm/x86（src/arch/arm/kvm、src/arch/x86/kvm）。 src/cpu/kvm/base.hh
• [S18] 经典缓存基类：BaseCache（:103）。 src/mem/cache/base.hh
• [S19] 内存控制器与介质抽象：MemCtrl（mem_ctrl.hh:246，类注释引用 ISPASS 2014）、MemInterface（mem_interface.hh:74）、DRAMInterface（dram_interface.hh:65）；DRAMSim2/3、DRAMSys、HBM 接线文件同目录。 src/mem/mem_ctrl.hh · dram_interface.hh
• [S20] Ruby 与 SLICC：L1 控制器机器声明示例（MESI_Two_Level-L1cache.sm:41）、SLICC 编译器（src/mem/slicc/parser.py）、RubySystem（system/RubySystem.hh:64）、CHI 协议目录。 MESI_Two_Level-L1cache.sm · src/mem/slicc/
• [S21] 统计框架：Group（group.hh:92）、Info（info.hh:79）、StatEvent 与转储调度（stat_control.cc:73/:106/:118）、Python API（m5/stats/__init__.py:312/:392/:439，text://stats.txt 约定 :85）、HDF5 输出（hdf5.hh:59）。 stat_control.cc · group.hh · stats/__init__.py
• [S22] 检查点序列化：SimObject::serializeAll（sim_object.cc:132）、CheckpointIn 基名 m5.cpt（serialize.cc:137）、Event 序列化字段（eventq.cc:265）。 sim_object.cc · serialize.cc
• [S23] RISC-V ISA 参数与 ISA 字符串：riscv_type（:95）、enable_rvv（:97）、vlen（:98）、elen（:103）、privilege_mode_set（:81/:108）、get_isa_string（:142）。 src/arch/riscv/RiscvISA.py
• [S24] RISC-V CPU 绑定与 RVV 实现：五个绑定类（RiscvCPU.py:44-60）、向量指令实现（insts/vector.cc，961 行）、ISA 解码器（isa/decoder.isa，6493 行）。 RiscvCPU.py · insts/vector.cc
• [S25] RISC-V 示例配置：RVV 示例（riscv-rvv-example.py:66-70）、riscvmatched hello（riscvmatched-hello.py，SE 模式，脚本头部含用法注释）、riscvmatched 全系统脚本（riscvmatched-fs.py:76-87）；develop 另含 riscv-ubuntu-run-with-kvm.py。 riscv-rvv-example.py · riscvmatched-hello.py · riscvmatched-fs.py
• [S26] SE/FS 负载面：Process 与系统调用模拟（src/sim/process.cc）；RiscvBootloaderKernelWorkload（RiscvFsWorkload.py:83，bootloader 地址 :91-92）；中断设备 PLIC/CLINT（src/dev/riscv/）。 RiscvFsWorkload.py · src/dev/riscv/plic.cc
• [S27] m5 客户端 RISC-V ABI：伪指令编码（m5op.S）、交叉编译默认值（SConsopts:29）。 m5op.S · 工具链 SConsopts
• [S28] riscvmatched 预置平台：板级参数（board.py:99/:119-120）、U74 核与功能单元（core.py:45-75/:109）、处理器核数（processor.py:50-55）、缓存层次。 riscvmatched_core.py · riscvmatched_board.py
• [S29] The gem5 Simulator: Version 20.0+（Lowe-Power 等，78 位作者，2020）：社区与提交量数据。 arXiv:2007.03152
• [S30] Toward Reproducible and Standardized Computer Architecture Simulation with gem5（Pai 等，v2 修订 2026-03）：1600+ fork、2000+ 预打包制品、Packer 标准化镜像、Suites/MultiSim。 arXiv:2512.13479
• [S31] gem5 贡献指南 CONTRIBUTING.md（同固定 commit）：议题认领流程（先留言、后认领）、拉取请求模型、develop 分支约定、主仓唯一性要求。 CONTRIBUTING.md
• [S32] gem5 治理页：精英制角色阶梯（用户/贡献者/维护者）、惰性共识决策、维护者提名与委员会投票。 gem5.org/governance
• [S33] GitHub 仓库与提交实测（REST API，2026-10-13）：主仓星标/复刻/贡献者/议题与默认分支（stable/develop）；src/arch/riscv 近 12 个月 87 笔提交、全仓 1,133 笔（作者日口径）及月度与作者聚合；RISC-V 相关已合并 PR 45、开放议题 38、开放 PR 23；src/arch/riscv/kvm/ 与 KVM 示例在 develop 的存在性核对。 gem5/gem5
• [S34] gem5-resources 的 RISC-V 资源目录：riscv-fs（OpenSBI 与 Ubuntu 22.04/24.04 镜像）、riscv-fs-alt（busybox 与无盘启动链）、GAPBS 与 NPB 的 RISC-V 构建脚本。 gem5-resources
• [S35] RISC-V KVM 支持：拉取请求 #3053（2026-08-14 合入 develop，26 个文件、新增 2,342 行、作者 selimsandal）：新增 RiscvKvmCPU（src/arch/riscv/kvm/）、PLIC 认领时同步清中断、riscv-ubuntu-run-with-kvm.py 示例。 pull/3053
• [S36] 配套调研：开源社区调研报告（2026-10-13，个人站点），含 gem5 社区贡献入口评估与 90 天行动计划。 oss-community-research
• [S37] gem5 提交全史与发布史实测（2026-10-13）：develop 分支完整 git 历史（24,600 笔，作者日期口径）中 src/arch/riscv 路径 851 笔的年度分布、作者与模块热度统计；主要 tag 提交日期；平台（riscvmatched）与设备（dev/riscv）路径历史；里程碑取对应主题首个提交。 gem5/gem5

附录 A：主要结论与依据对照

附录 B：检查与验收清单

附录 C：研究方法与局限

本报告以固定 commit 的只读克隆为唯一源码依据：2026-10-13 浅克隆 gem5 主仓库至 tag v25.1.0.1（commit c8222cc6），全程不安装、不构建、不运行仿真器；所有机制结论先取逐字源码片段与行号，再行文引用，引用的行号即该 commit 下的行号。外部材料取自两篇 arXiv 论文、官方 README/RELEASE-NOTES 与官网入口，均按摘要与原文口径引用。研究限制有四：其一，未运行任何 gem5 实验，凡涉及运行结果、性能数字与覆盖度结论均显式降级为「未知」或验证命令，不替读者下结论；其二，抽查式覆盖——六个机制小节优先选取装配、内核、CPU、存储、可复现与 RISC-V 主线，GPU、SystemC、SST 等旁支未逐项核查；其三，行号随版本漂移，本报告所有行号只对 commit c8222cc6 有效，升版复核应以文件与符号名为锚重新定位；其四，社区与生态数据（fork 数、制品数、贡献者数）来自论文发表时点，与当前时点可能存在偏差。v1.1 增补的社区数据是同一方法的延伸，来自 GitHub REST API 单日实测（2026-10-13）：提交按月与作者聚合时对同一人的不同署名做了合并标注；「RISC-V 相关拉取请求与议题计数」为全文检索口径（标题或正文包含 riscv），存在少量漏计；develop 侧新动向（如 KVM）与快照结论已在正文分栏标注，避免混用。v1.2 的提交史统计统一采用作者日期（author date）口径：GitHub API 的 since/until 过滤按提交者日期执行，且早期历史经仓库迁移改写后该口径明显失真（2016 年窗口会误报为零），因此改用本地完整 git 全史统计（24,600 笔全史与 851 笔 RISC-V 路径）；里程碑取其主题的首个提交，五个阶段划分为本报告基于提交形态的归纳而非项目官方分期。复现建议：以本文附录 B 的命令逐条复查，再以 riscv-rvv-example 与 riscvmatched-fs 两个脚本为最小上手路径展开实验。

附录 D：术语与缩略语