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 用的是 PLICPlatform-Level Interrupt Controller和 CLINTCore-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 日志解析输出判断启动到了哪个阶段OpenSBIU-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-listriscv64-softmmu \ --enable-debug \ --enable-trace-backendslog \ --disable-werror # 编译-j 后面跟你的 CPU 核心数 make -j$(nproc) sudo make install这里有几个参数值得解释--target-listriscv64-softmmu只编译 RISC-V 64 位的系统模拟不编译用户态模拟和其他架构。这样编译时间从半小时缩短到几分钟。--enable-debug保留调试符号方便后面用 gdb 跟 QEMU 内部逻辑。如果你只是跑环境可以去掉。--enable-trace-backendslog开启 trace 功能输出到日志文件。这个对调试 PCIe 枚举过程至关重要后面会详细讲。--disable-werror把警告当错误关掉。新版编译器对老代码的警告很多不开这个编译会中断。提示编译前确认装了libglib2.0-dev、libpixman-1-dev、ninja-build这几个依赖缺一个都会 configure 失败。3.2 RISC-V 工具链与固件QEMU 只是模拟硬件你还需要能跑在上面的软件。最小集合是OpenSBIRISC-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 环境搭建这种系统级操作场景选型要看三个能力命令执行能力能跑 shell 命令能拿到 stdout/stderr 和退出码。文件读写能力能生成和修改 QEMU 配置、DTB 源文件、启动脚本。长上下文与反馈循环能记住之前试过什么参数、失败原因是什么避免重复试错。我自己的选择是一个支持工具调用的通用 AGENT 框架核心是给它定义好工具集run_qemu、parse_serial_log、modify_dtb、check_pci。框架本身不重要重要的是工具定义要清晰反馈要结构化。这里要区分 AGENT 和 harnessharness 是你写死的测试流程比如启动 QEMU - 等 30 秒 - 跑 lspci - 检查输出。AGENT 则是你给它目标它自己决定先做什么、失败了怎么办。在环境搭建阶段AGENT 更合适因为失败模式太多你没法穷举。4. 核心配置从零拉起一个带 PCIe 的 RISC-V 虚拟机4.1 最小可启动命令行的拆解先给你一条能跑起来的最小命令然后逐段解释qemu-system-riscv64 \ -M virt,pcion \ -cpu rv64 \ -smp 4 \ -m 4G \ -kernel opensbi-riscv64-virt-fw_jump.bin \ -append root/dev/vda rw consolettyS0 \ -drive filerootfs.ext4,formatraw,idhd0 \ -device virtio-blk-pci,drivehd0 \ -nographic逐段拆-M virt,pcion使用 QEMU 的 RISC-Vvirt虚拟平台并开启 PCIe 支持。这个pcion是关键不开的话后面加 PCIe 设备会失败。-cpu rv6464 位 RISC-V 通用 CPU。如果要模拟特定扩展比如向量指令可以改成rv64,vtrue。-smp 44 个核心。AI 芯片验证经常需要多核因为驱动可能用多队列。-m 4G4GB 内存。AI 加速器的 BAR 空间映射和 DMA 缓冲区需要足够内存。-kernel这里加载的是 OpenSBI 固件。注意QEMU 的-kernel参数在 RISC-V 上加载的是 M-mode 固件不是 Linux 内核。Linux 内核是通过-append里的参数让 OpenSBI 去加载的或者用-bios指定。-append传递给内核的启动参数。consolettyS0让内核输出到串口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,dumpdtbvirt.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 控制器节点大概长这样pci30000000 { 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 大小 16MBMSI-X 中断输出是完整的 QEMU 命令行和 DTB 修改补丁。AGENT 的工作流程是这样的解析目标描述提取关键参数核心数、内存、设备类型、BAR 大小、中断方式调用qemu-system-riscv64 -M virt,dumpdtb导出基础 DTB用dtc反编译定位 PCIe 控制器节点根据 BAR 大小计算 MMIO 地址范围插入到ranges属性根据 MSI-X 需求配置interrupt-map重新编译 DTB生成启动脚本执行启动脚本捕获串口输出如果启动失败解析错误信息回到步骤 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/resourcelspci -vvv会显示设备的 vendor ID、device ID、BAR 大小、中断信息、链路状态。如果设备没出现说明枚举失败常见原因有DTB 里 PCIe 控制器的ranges没覆盖设备 BAR 地址interrupt-map配置错误导致中断路由失败设备本身的 vendor/device ID 是 0xFFFFQEMU 没正确初始化设备这里有个技巧用 QEMU 的 trace 功能看枚举过程。启动 QEMU 时加上-trace pci* -trace msix* -trace aer*这样 QEMU 会把所有 PCIe 相关的操作打到日志里包括配置空间读写、BAR 分配、MSI-X 表初始化、AER 错误上报。这个日志比内核的 dmesg 详细得多是排查枚举问题的第一手资料。5.3 PCIe 热插拔与 AER 的模拟AI 芯片验证里热插拔和 AERAdvanced Error Reporting是两个高频场景。QEMU 对这两个都有支持。热插拔的模拟方式是在 QEMU monitor 里执行device_add和device_del。比如# 在 QEMU monitor 里Ctrl-A C 进入 device_add edu,idai0,buspcie.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-backendslog并且设备要支持 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。具体改法是修改pci30000000节点下的ranges属性增加一段0x03000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000这样的映射。6.3 中断不通MSI-X 路由的排查链路第三个坑最隐蔽设备能识别BAR 能映射但中断收不到。驱动发命令给设备设备应该回一个 MSI-X 中断但内核那边毫无反应。排查链路确认设备支持 MSI-Xlspci -vvv里看 Capabilities 有没有 MSI-X。确认内核启用了 MSI-Xdmesg | grep -i msix看有没有 enabling MSI-X 的日志。确认 MSI-X 表地址正确lspci -vvv里看 MSI-X 的 Table BIR 和 Offset对比设备驱动里读到的值。确认中断路由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,idrp0,buspcie.0,x-speed2,x-width4这样 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 能自动化这套流程关键是定义好工具。我的工具集是这样的工具名功能输入输出run_qemu启动 QEMU 并捕获输出命令行参数、超时时间串口日志、退出码parse_boot_stage判断启动到了哪个阶段串口日志阶段枚举firmware/kernel/userspacedump_dtb导出并反编译 DTB无dts 文本modify_dtb修改 DTB 节点节点路径、属性、值修改后的 dtscompile_dtb编译 DTBdts 文本dtb 文件路径check_pci在 guest 里检查 PCIe 设备设备 ID是否存在、BAR 信息inject_aer注入 AER 错误设备地址、错误类型成功/失败这些工具定义好之后AGENT 就能根据目标自主编排。比如目标是启动一个带 edu 设备的 RISC-V Linux并确认设备可访问AGENT 会调用run_qemu启动基础环境调用parse_boot_stage确认启动成功调用dump_dtb和modify_dtb添加 PCIe 设备节点调用compile_dtb生成新 DTB再次run_qemu这次带上新 DTB 和-device edu调用check_pci确认设备出现如果失败根据错误信息回到步骤 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 枚举的完整流程比看十篇文章都管用。