企业官网建设流程全解析

1. 为什么我要用 AGENT 来搭 RISC-V 的 QEMU 实验台

先说结论：如果你打算认真折腾 RISC-V 架构下的 AI 芯片验证，纯手工敲 QEMU 命令行的方式，撑不过第三天就会崩溃。这不是夸张，是我自己踩了整整一周坑之后得出的血泪结论。

我最初的想法很朴素——QEMU 嘛，不就是qemu-system-riscv64加几个参数的事？网上教程一搜一大把，跟着敲就完了。结果真正上手才发现，RISC-V 的 QEMU 环境搭建远没有 ARM 那么"开箱即用"。你要面对的是：设备树（Device Tree）要自己拼、PCIe 拓扑要手动描述、AI 加速器的 MMIO 区域要精确映射、固件和内核的加载地址稍有偏差就直接 triple fault。更别提后面还要模拟 PCIe 热插拔、AER 报错注入、链路降速这些真实芯片验证场景。

这时候 AGENT 的价值就体现出来了。我这里说的 AGENT，不是那种"帮你写代码"的泛泛 AI 助手，而是一个具备工具调用能力、能自主执行命令、能根据输出反馈调整下一步动作的自动化代理。它和 harness 的区别在于：harness 是你写好的固定测试脚本，输入输出都是预设的；而 AGENT 是"活的"，它能看 QEMU 的串口输出、能解析 dmesg、能根据 PCIe 枚举结果决定下一步是重试还是换配置。

打个比方：harness 像是流水线上的机械臂，动作精确但只会做一件事；AGENT 像是一个刚入职但很聪明的实验员，你告诉他"把这块 RISC-V 板子拉起来，确认 PCIe 上能认到 AI 加速器"，他会自己去找工具、试参数、看日志、调配置，直到跑通或者明确告诉你卡在哪。

这篇文章要讲的就是：如何用 AGENT 驱动的方式，从零搭建一套 RISC-V AI 芯片的 QEMU 实验台。适合谁看？三类人：一是做 RISC-V 芯片前期验证的工程师，需要在流片前用 QEMU 跑通软件栈；二是做 AI 加速器驱动开发的，想在没有真实硬件的情况下调试 PCIe 枚举和 MMIO 访问；三是想学习 AGENT 实战落地的开发者，QEMU 环境搭建是一个非常好的"工具调用 + 反馈循环"练手场景。

整篇内容我会按照真实搭建顺序展开：先讲清楚 QEMU 在 RISC-V AI 芯片验证里到底扮演什么角色，再讲 AGENT 怎么介入这个流程，然后是环境准备、核心配置、PCIe 模拟、踩坑排查，最后是我自己总结的一套可复用的 AGENT 工作流。全程给命令、给配置、给参数解释，你照着抄就能跑。

2. QEMU 在 RISC-V AI 芯片验证中的真实定位

2.1 它不是"模拟器"，是"软件栈验证平台"

很多人对 QEMU 的理解停留在"模拟一个 CPU 跑跑程序"。但在 RISC-V AI 芯片的开发流程里，QEMU 的定位要重要得多——它是流片前唯一的全系统软件验证环境。

一块 AI 芯片从设计到流片，中间有长达数月的窗口期，这期间没有物理硬件。但软件团队不能干等，驱动、固件、运行时、算子库都得提前开发。QEMU 就是用来填补这个空窗期的：它模拟出 CPU 核心、内存控制器、PCIe 总线、中断控制器，让 AI 加速器以一个"虚拟 PCIe 设备"的形式挂上去，软件团队就能像操作真机一样去枚举设备、映射 BAR 空间、读写寄存器、触发 DMA。

这里的关键词是PCIe。RISC-V AI 芯片绝大多数都是通过 PCIe 接口挂到主机上的（不管是作为加速卡还是作为 SoC 内的一个端点）。所以 QEMU 实验台的核心，其实就是把 PCIe 拓扑模拟对。PCIe 枚举过程、BAR 空间分配、MSI-X 中断、链路训练、热插拔、AER 错误上报——这些在真机上要示波器和协议分析仪才能看的东西，在 QEMU 里都能通过日志和 trace 观察到。

2.2 RISC-V 相比 ARM 在 QEMU 上的额外复杂度

如果你之前用 QEMU 模拟过 ARM64 平台，会觉得"不就是换个 machine type 吗"。但 RISC-V 有几个额外的坑：

第一，设备树（DTB）的生成方式不同。ARM 的 QEMU 虚拟平台（比如virt）会自动生成 DTB 并通过-dtb或固件传递，生态成熟。RISC-V 的virt机器虽然也支持自动生成，但一旦你要添加自定义的 AI 加速器 PCIe 设备，就必须手动修改 DTB 或者用 QEMU 的-device参数精确描述，否则内核根本发现不了设备。

第二，中断控制器的差异。RISC-V 用的是 PLIC（Platform-Level Interrupt Controller）和 CLINT（Core-Local Interruptor），跟 ARM 的 GIC 完全不是一套东西。PCIe 的 MSI/MSI-X 中断在 RISC-V 上怎么路由到 PLIC，需要你在 QEMU 配置里显式指定。

第三，固件层（OpenSBI）的存在。RISC-V 的启动流程是：QEMU 加载 OpenSBI 作为 M-mode 固件，OpenSBI 再跳转到 S-mode 的 U-Boot 或 Linux。这个链条比 ARM 多一层，任何一环的加载地址错了都会导致启动失败。

2.3 AGENT 介入的切入点在哪里

理解了上面这些，你就明白为什么纯手工搭环境会崩溃——配置空间太大，反馈太慢，试错成本太高。

一个典型的搭建流程涉及：选择 machine type、配置 CPU 核心数和扩展指令集、分配内存、挂载根文件系统、指定内核和 DTB、添加 PCIe 设备、配置网络、设置串口输出。任何一个参数错了，表现可能都是"启动到一半卡住"或者"内核 panic"，你得从一堆日志里找线索。

AGENT 的切入点就是把这个"配置-启动-观察-调整"的循环自动化。具体来说，AGENT 能做这几件事：

• 根据目标（比如"启动一个带 PCIe AI 设备的 RISC-V Linux"）自动生成 QEMU 命令行
• 执行 QEMU，捕获串口输出和 QEMU 自身的 trace 日志
• 解析输出，判断启动到了哪个阶段（OpenSBI？U-Boot？内核？用户态？）
• 如果失败，根据错误类型调整参数重试（比如地址冲突就改加载地址，设备不识别就改 DTB）
• 成功启动后，自动执行验证脚本（lspci 看设备、读 BAR、触发中断）

这套流程用 harness 也能做，但 harness 只能处理你预设好的失败模式。AGENT 的优势在于能处理"意料之外"的失败——比如内核报了一个你没见过的 AER 错误，AGENT 可以去查文档、调整配置、再试。

3. 搭建前的环境准备与工具选型

3.1 QEMU 版本选择：为什么我坚持用源码编译

系统自带的 QEMU 版本往往太老，RISC-V 的新特性和 PCIe 模拟功能支持不全。我实测下来，QEMU 8.0 以上才比较稳定地支持 RISC-V virt 机器上的 PCIe 设备和热插拔。Ubuntu 22.04 自带的 QEMU 是 6.2，直接用它会在添加 PCIe 设备时报 "unsupported machine" 或者设备根本不出现。

所以第一步是源码编译。别怕，QEMU 的编译没那么恐怖，关键是选对 configure 参数：

# 下载源码（以 8.2 为例） wget https://download.qemu.org/qemu-8.2.0.tar.xz tar xf qemu-8.2.0.tar.xz cd qemu-8.2.0 # 配置：只编译我们需要的目标架构，加快编译速度 ./configure --target-list=riscv64-softmmu \ --enable-debug \ --enable-trace-backends=log \ --disable-werror # 编译（-j 后面跟你的 CPU 核心数） make -j$(nproc) sudo make install

这里有几个参数值得解释：

• --target-list=riscv64-softmmu：只编译 RISC-V 64 位的系统模拟，不编译用户态模拟和其他架构。这样编译时间从半小时缩短到几分钟。
• --enable-debug：保留调试符号，方便后面用 gdb 跟 QEMU 内部逻辑。如果你只是跑环境，可以去掉。
• --enable-trace-backends=log：开启 trace 功能，输出到日志文件。这个对调试 PCIe 枚举过程至关重要，后面会详细讲。
• --disable-werror：把警告当错误关掉。新版编译器对老代码的警告很多，不开这个编译会中断。

提示：编译前确认装了libglib2.0-dev、libpixman-1-dev、ninja-build这几个依赖，缺一个都会 configure 失败。

3.2 RISC-V 工具链与固件

QEMU 只是模拟硬件，你还需要能跑在上面的软件。最小集合是：

• OpenSBI：RISC-V 的 M-mode 固件，负责初始化硬件、提供 SBI 接口。QEMU 自带了一个预编译的opensbi-riscv64-virt-fw_jump.bin，但如果你想定制，可以自己编译。
• U-Boot（可选）：如果你需要更复杂的启动流程（比如从网络加载内核），需要 U-Boot。简单场景可以跳过，让 OpenSBI 直接跳内核。
• Linux 内核：需要编译支持 RISC-V 和 PCIe 的内核。推荐用 6.1 以上的 LTS 版本。
• 根文件系统：可以用 Buildroot 或 Yocto 生成，也可以直接用现成的 RISC-V rootfs 镜像。

工具链方面，riscv64-linux-gnu-系列（gcc、binutils）是必须的。Ubuntu 上直接apt install gcc-riscv64-linux-gnu就行。

3.3 AGENT 框架的选择思路

AGENT 框架现在满天飞，但做 QEMU 环境搭建这种"系统级操作"场景，选型要看三个能力：

1. 命令执行能力：能跑 shell 命令，能拿到 stdout/stderr 和退出码。
2. 文件读写能力：能生成和修改 QEMU 配置、DTB 源文件、启动脚本。
3. 长上下文与反馈循环：能记住之前试过什么参数、失败原因是什么，避免重复试错。

我自己的选择是一个支持工具调用的通用 AGENT 框架，核心是给它定义好工具集：run_qemu、parse_serial_log、modify_dtb、check_pci。框架本身不重要，重要的是工具定义要清晰，反馈要结构化。

这里要区分 AGENT 和 harness：harness 是你写死的测试流程，比如"启动 QEMU -> 等 30 秒 -> 跑 lspci -> 检查输出"。AGENT 则是你给它目标，它自己决定先做什么、失败了怎么办。在环境搭建阶段，AGENT 更合适，因为失败模式太多，你没法穷举。

4. 核心配置：从零拉起一个带 PCIe 的 RISC-V 虚拟机

4.1 最小可启动命令行的拆解

先给你一条能跑起来的最小命令，然后逐段解释：

qemu-system-riscv64 \ -M virt,pci=on \ -cpu rv64 \ -smp 4 \ -m 4G \ -kernel opensbi-riscv64-virt-fw_jump.bin \ -append "root=/dev/vda rw console=ttyS0" \ -drive file=rootfs.ext4,format=raw,id=hd0 \ -device virtio-blk-pci,drive=hd0 \ -nographic

逐段拆：

• -M virt,pci=on：使用 QEMU 的 RISC-Vvirt虚拟平台，并开启 PCIe 支持。这个pci=on是关键，不开的话后面加 PCIe 设备会失败。
• -cpu rv64：64 位 RISC-V 通用 CPU。如果要模拟特定扩展（比如向量指令），可以改成rv64,v=true。
• -smp 4：4 个核心。AI 芯片验证经常需要多核，因为驱动可能用多队列。
• -m 4G：4GB 内存。AI 加速器的 BAR 空间映射和 DMA 缓冲区需要足够内存。
• -kernel：这里加载的是 OpenSBI 固件。注意，QEMU 的-kernel参数在 RISC-V 上加载的是 M-mode 固件，不是 Linux 内核。Linux 内核是通过-append里的参数让 OpenSBI 去加载的（或者用-bios指定）。
• -append：传递给内核的启动参数。console=ttyS0让内核输出到串口，root=/dev/vda指定根文件系统。
• -drive+-device virtio-blk-pci：挂载根文件系统。注意这里用的是 virtio-blk-pci，走的是 PCIe 总线，这本身就是一次 PCIe 设备枚举的练习。
• -nographic：不开图形界面，所有输出走串口。这是服务器环境的标准做法。

4.2 设备树的手动调整：让内核认识你的 AI 设备

QEMU 的virt机器会自动生成设备树，但自动生成的 DTB 里只有 QEMU 内置的设备。当你用-device添加一个自定义 PCIe 设备时，如果这个设备的 vendor ID 和 device ID 不在内核的已知列表里，内核就不会加载驱动。

解决办法有两个：一是改内核驱动让它匹配你的 ID，二是手动修改 DTB 添加设备节点。实际项目中通常两个都做。这里讲 DTB 的手动调整：

# 从 QEMU 导出自动生成的 DTB qemu-system-riscv64 -M virt,dumpdtb=virt.dtb -smp 4 -m 4G -nographic # 反编译成可读的 dts dtc -I dtb -O dts -o virt.dts virt.dtb # 编辑 virt.dts，在 pci 节点下添加你的设备 # 然后重新编译 dtc -I dts -O dtb -o virt-modified.dtb virt.dts

在virt.dts里，PCIe 控制器节点大概长这样：

pci@30000000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; reg = <0x0 0x30000000 0x0 0x10000000>; bus-range = <0x00 0xff>; ranges = <...>; interrupt-map = <...>; interrupt-map-mask = <...>; };

你要做的是在ranges里确保 MMIO 区域覆盖你的 AI 设备 BAR 空间，在interrupt-map里确保 MSI-X 中断能正确路由。这部分最容易出错，因为地址算错一位，内核就找不到设备。

注意：手动改 DTB 后，启动命令里要用-dtb virt-modified.dtb显式指定，否则 QEMU 还是会用自动生成的。

4.3 用 AGENT 自动化配置生成

手工改 DTB 很痛苦，尤其是当你需要反复调整地址映射的时候。这时候 AGENT 就能帮上忙。我给 AGENT 定义了一个工具generate_qemu_config，输入是目标描述（比如"RISC-V 4 核，4G 内存，一个 PCIe AI 设备，BAR0 大小 16MB，MSI-X 中断"），输出是完整的 QEMU 命令行和 DTB 修改补丁。

AGENT 的工作流程是这样的：

1. 解析目标描述，提取关键参数（核心数、内存、设备类型、BAR 大小、中断方式）
2. 调用qemu-system-riscv64 -M virt,dumpdtb导出基础 DTB
3. 用dtc反编译，定位 PCIe 控制器节点
4. 根据 BAR 大小计算 MMIO 地址范围，插入到ranges属性
5. 根据 MSI-X 需求配置interrupt-map
6. 重新编译 DTB，生成启动脚本
7. 执行启动脚本，捕获串口输出
8. 如果启动失败，解析错误信息，回到步骤 4 调整

这套流程里，AGENT 的核心价值是步骤 4 到 8 的循环。地址映射这种东西，手工算很容易错，但让 AGENT 去试，它可以在几分钟内试完几十种组合。

5. PCIe 设备模拟：AI 加速器怎么"挂"上去

5.1 QEMU 内置 PCIe 设备 vs 自定义设备

QEMU 自带了不少 PCIe 设备模型：virtio-net-pci、virtio-blk-pci、e1000e、nvme等等。这些可以直接用-device挂上去，用来验证 PCIe 枚举流程没问题。

但 AI 加速器是自定义设备，QEMU 没有现成模型。你有两个选择：

选择一：用pci-testdev或edu设备模拟。QEMU 自带一个edu设备（-device edu），它是一个教学用的 PCI 设备，有 BAR、有中断、有 DMA。你可以把它当成 AI 加速器的"替身"，先跑通驱动框架，等真实设备模型开发好了再替换。这是最省事的做法。

选择二：写一个 QEMU 设备模型。如果你需要精确模拟 AI 加速器的寄存器行为，就得用 C 写一个 QEMU 设备。这属于进阶内容，本文不展开，但思路是：继承PCIDevice类，实现realize、mmio_read、mmio_write、dma等回调。

对于环境搭建阶段，我强烈建议先用edu设备跑通全流程。等 PCIe 枚举、BAR 映射、中断、DMA 都验证过了，再替换成自定义设备模型。

5.2 PCIe 枚举过程的观察与验证

设备挂上去之后，怎么确认内核真的枚举到了？在 QEMU 里跑起 Linux 后，执行：

# 查看 PCIe 设备列表 lspci -vvv # 查看内核 PCIe 枚举日志 dmesg | grep -i pci # 查看具体设备的 BAR 空间 cat /sys/bus/pci/devices/0000:00:01.0/resource

lspci -vvv会显示设备的 vendor ID、device ID、BAR 大小、中断信息、链路状态。如果设备没出现，说明枚举失败，常见原因有：

• DTB 里 PCIe 控制器的ranges没覆盖设备 BAR 地址
• interrupt-map配置错误，导致中断路由失败
• 设备本身的 vendor/device ID 是 0xFFFF（QEMU 没正确初始化设备）

这里有个技巧：用 QEMU 的 trace 功能看枚举过程。启动 QEMU 时加上：

-trace "pci*" -trace "msix*" -trace "aer*"

这样 QEMU 会把所有 PCIe 相关的操作打到日志里，包括配置空间读写、BAR 分配、MSI-X 表初始化、AER 错误上报。这个日志比内核的 dmesg 详细得多，是排查枚举问题的第一手资料。

5.3 PCIe 热插拔与 AER 的模拟

AI 芯片验证里，热插拔和 AER（Advanced Error Reporting）是两个高频场景。QEMU 对这两个都有支持。

热插拔的模拟方式是：在 QEMU monitor 里执行device_add和device_del。比如：

# 在 QEMU monitor 里（Ctrl-A C 进入） device_add edu,id=ai0,bus=pcie.0 # 等几秒 device_del ai0

内核那边会收到热插拔事件，dmesg 里能看到pciehp相关的日志。你可以用 AGENT 自动化这个过程：添加设备 -> 等待内核识别 -> 检查 lspci -> 删除设备 -> 检查内核是否正确清理。

AER 的模拟稍微复杂一点。QEMU 支持通过 monitor 命令注入 AER 错误：

# 注入一个 correctable error pcie_aer_inject_error 0000:00:01.0 correctable

注入后，内核的 AER 驱动会收到中断，dmesg 里会打印错误详情。这个功能用来验证驱动的错误处理逻辑非常有用。

提示：AER 注入需要 QEMU 编译时开启--enable-trace-backends=log，并且设备要支持 AER 能力。edu设备默认不支持，你可能需要用pcie-root-port或者自定义设备。

6. 踩坑实录：那些让我熬夜的 PCIe 问题

6.1 设备不出现：从枚举日志倒推配置错误

这是我遇到的第一个坑，也是最耗时的。现象是：QEMU 启动正常，Linux 也起来了，但lspci里死活看不到我添加的设备。

排查过程是这样的：

第一步，确认 QEMU 命令行里设备确实加上了。用-device edu后，QEMU 启动时如果参数错误会直接报错退出，所以能启动就说明设备模型加载了。

第二步，看 QEMU trace 日志。加上-trace "pci*"后，日志里能看到 QEMU 在配置空间里写了 vendor ID 和 device ID，说明设备在 QEMU 层面是存在的。

第三步，看内核 dmesg。发现内核的 PCIe 控制器驱动只扫描了 bus 0，而我的设备被 QEMU 分配到了 bus 1。原因是pcie.0总线上挂了一个pcie-root-port，设备挂在 root port 下面，所以 bus 号是 1。但内核的pci-host-ecam-generic驱动配置的bus-range是<0x00 0x00>，只扫描 bus 0。

解决办法：修改 DTB 里的bus-range为<0x00 0xff>，让内核扫描所有 bus。改完后设备立刻出现了。

这个坑的教训是：QEMU 的 PCIe 拓扑和 DTB 的 bus-range 必须匹配。QEMU 默认会把设备挂在 root port 下面，产生多级 bus，而自动生成的 DTB 有时只配置了 bus 0。

6.2 BAR 空间冲突：地址分配的那些门道

第二个坑是 BAR 空间冲突。现象是：设备出现了，但驱动probe失败，报 "cannot reserve BAR" 或者 "address conflict"。

原因是 QEMU 给设备分配的 BAR 地址和 DTB 里ranges定义的 MMIO 区域重叠了。QEMU 的 PCIe 地址分配逻辑是：从ranges定义的 MMIO 窗口里找空闲区域分配给 BAR。如果ranges窗口太小，或者已经被其他设备占满，新设备就分不到地址。

排查方法：看/proc/iomem，找到 PCIe 总线对应的 MMIO 区域，对比lspci -vvv里设备的 BAR 地址。如果 BAR 地址不在 MMIO 区域内，就是ranges配置问题。

解决办法：扩大 DTB 里ranges的 MMIO 窗口。比如原来只有 256MB，改成 1GB。具体改法是修改pci@30000000节点下的ranges属性，增加一段<0x03000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>这样的映射。

6.3 中断不通：MSI-X 路由的排查链路

第三个坑最隐蔽：设备能识别，BAR 能映射，但中断收不到。驱动发命令给设备，设备应该回一个 MSI-X 中断，但内核那边毫无反应。

排查链路：

1. 确认设备支持 MSI-X：lspci -vvv里看 Capabilities 有没有 MSI-X。
2. 确认内核启用了 MSI-X：dmesg | grep -i msix，看有没有 "enabling MSI-X" 的日志。
3. 确认 MSI-X 表地址正确：lspci -vvv里看 MSI-X 的 Table BIR 和 Offset，对比设备驱动里读到的值。
4. 确认中断路由：RISC-V 上 MSI-X 中断要通过interrupt-map路由到 PLIC。检查 DTB 里的interrupt-map是否包含了 PCIe 控制器的中断映射。

我最后发现问题是第 4 步：DTB 里的interrupt-map只映射了 legacy INTx 中断，没有映射 MSI-X。RISC-V 的pci-host-ecam-generic驱动对 MSI-X 的支持需要 DTB 里有正确的msi-parent属性，指向 PLIC 的 MSI 控制器。

解决办法：在 DTB 的 PCIe 控制器节点里添加msi-parent = <&plic>，并确保 PLIC 节点有msi-controller属性。

6.4 链路降速与 AER 报错的模拟验证

第四个坑是关于链路稳定性的。真实 AI 芯片在 PCIe 链路上经常遇到降速（从 Gen4 降到 Gen3）和 AER 报错。QEMU 可以模拟这些场景，但配置起来有讲究。

模拟链路降速：QEMU 的pcie-root-port支持x-speed和x-width参数。比如：

-device pcie-root-port,id=rp0,bus=pcie.0,x-speed=2,x-width=4

这样 root port 会以 Gen2 x4 的速率训练链路。内核启动后，lspci -vvv里会显示 "LnkSta: Speed 2.5GT/s, Width x4"，说明降速模拟成功。

模拟 AER 报错：用 monitor 命令pcie_aer_inject_error。但要注意，注入的错误类型要和设备支持的 AER 能力匹配。比如设备只支持 correctable error，你注入 fatal error 就会被忽略。

验证 AER 是否生效：看 dmesg 里有没有aer相关的日志，以及/sys/bus/pci/devices/.../aer_dev_correctable等计数文件是否增加。

7. 把 AGENT 用起来：一套可复用的工作流

7.1 定义 AGENT 的工具集

前面讲了这么多手工操作，现在回到 AGENT 的主线。要让 AGENT 能自动化这套流程，关键是定义好工具。我的工具集是这样的：

这些工具定义好之后，AGENT 就能根据目标自主编排。比如目标是"启动一个带 edu 设备的 RISC-V Linux，并确认设备可访问"，AGENT 会：

1. 调用run_qemu启动基础环境
2. 调用parse_boot_stage确认启动成功
3. 调用dump_dtb和modify_dtb添加 PCIe 设备节点
4. 调用compile_dtb生成新 DTB
5. 再次run_qemu，这次带上新 DTB 和-device edu
6. 调用check_pci确认设备出现
7. 如果失败，根据错误信息回到步骤 3 调整

7.2 反馈循环的设计：让 AGENT 知道"错在哪"

AGENT 能不能高效工作，取决于反馈信息够不够结构化。如果只给它一堆原始日志，它很难定位问题。所以我在run_qemu工具里做了日志预处理：

• 提取关键行：包含 "error"、"fail"、"panic"、"timeout" 的行
• 标记启动阶段：在日志里插入阶段标记（比如看到 "OpenSBI" 就标记 firmware 阶段完成）
• 提取 PCIe 相关：过滤出包含 "pci"、"bar"、"msi" 的行

这样 AGENT 拿到的不是几千行日志，而是几十行关键信息，决策效率高很多。

7.3 从"能跑"到"跑得稳"：AGENT 的自我校验

环境搭起来只是第一步，更重要的是验证它稳定可靠。我让 AGENT 做了一套自我校验流程：

• 连续启动 10 次，确认每次都能正常启动（排除偶发问题）
• 热插拔设备 20 次，确认内核每次都能正确识别和清理
• 注入 100 次 AER 错误，确认驱动都能正确处理
• 改变链路速率和宽度，确认驱动能自适应

这套校验跑下来，基本能覆盖 80% 的真实场景问题。剩下的 20% 需要真实硬件才能暴露，但至少软件栈的逻辑是对的。

8. 一些让我少走弯路的心得

折腾完这一整套，我有几个体会想分享。

第一，不要一上来就追求"完整模拟"。我最初想一步到位，直接把 AI 加速器的所有寄存器行为都模拟出来，结果卡在设备模型开发上两周。后来退一步，先用edu设备跑通 PCIe 枚举和驱动框架，等软件栈稳定了再替换设备模型，效率高得多。环境搭建要遵循"先通后精"的原则。

第二，QEMU 的 trace 日志比什么都重要。内核的 dmesg 只告诉你"结果"，QEMU 的 trace 告诉你"过程"。PCIe 枚举的每一步、配置空间的每次读写、MSI-X 表的初始化，trace 里都有。我排查 BAR 冲突和中断路由问题时，全靠 trace 日志定位。

第三，DTB 是 RISC-V QEMU 环境的核心，值得花时间搞懂。ARM 上你可能一辈子不用碰 DTB，但 RISC-V 上不行。设备树里的ranges、interrupt-map、msi-parent这几个属性，直接决定了 PCIe 设备能不能被正确识别。建议花半天时间把virt.dts从头到尾读一遍，理解每个节点的作用。

第四，AGENT 不是银弹，工具定义才是关键。我见过很多人抱怨 AGENT "不好用"，其实问题往往出在工具定义太粗糙。给 AGENT 的工具要像给新人的操作手册一样清晰：输入是什么、输出是什么、失败了返回什么。工具定义好了，AGENT 的决策质量自然就上去了。

最后分享一个小技巧：如果你在 QEMU 里调试 PCIe 驱动，可以用-S -s参数让 QEMU 启动时暂停并监听 gdb。然后gdb-multiarch vmlinux连上去，在 PCIe 枚举的关键函数（比如pci_scan_root_bus）下断点，单步跟一遍。这个过程虽然慢，但能让你彻底理解 PCIe 枚举的完整流程，比看十篇文章都管用。