1. 为什么非要在 QEMU 里搭一个 RISC-V AI 芯片实验台最近我一直在折腾一件事用 AI Agent 辅助搭一套 QEMU 模拟环境目标是纯软件链路下拉起一块 RISC-V 架构的 AI 芯片实验台。很多人一听就皱眉——芯片实验台不应该是真芯片加开发板吗模拟器能顶什么用我的回答是能顶大用尤其在 AI 芯片开发周期里。真实的 SoC 板子流片周期长、价格贵软件团队想在硬件回来之前就把编译器、运行时、推理框架跑通唯一的选择就是指令集模拟器。QEMU 在这里不是一个玩具而是整个软件栈预研的基础设施。RISC-V 这几年能火起来很大一部分功劳要记在 QEMU 这种开放仿真平台身上——你不需要一块真实芯片就能把 Linux、GCC/LLVM 工具链、PyTorch 运行时全部提前踩一遍。这个实验台适合谁三类人最需要做 RISC-V AI 芯片软件栈开发的工程师需要在硬件回来前搞定交叉编译、启动流程、驱动验证做 AI 框架适配的同学想在 RISC-V 平台上验证算子实现、向量扩展RVV的性能基线单纯想学 QEMU 和 RISC-V 的学生或爱好者用一套纯软件环境把芯片级 Linux 系统跑起来比买开发板门槛低得多。还有一个隐藏角色值得一说Agent。整个搭建过程里我让 AI Agent 承担了查文档、生成脚本、分析启动日志、修 bug的活。传统做法是人在键盘前反复试错这次我换了个玩法——把 Agent 当协作工程师用。这个思路后面会详细展开。QEMU 模拟 RISC-V 平台这件事本身不复杂复杂的是模拟出来的东西到底能不能当 AI 芯片实验台来用。如果你的目标只是让内核启动到控制台那一条 qemu-system-riscv64 命令就够了。但如果要跑 AI 推理、验证向量指令、复现芯片行为就需要从模拟器特性到内核配置到 rootfs 一步步深挖。这篇文章就是把这条链路完整拆给你看。2. 方案选型为什么选 QEMU virt 机器为什么关注向量扩展2.1 先别急着选板子先搞懂 QEMU 的三种 RISC-V 玩法QEMU 对 RISC-V 的支持分成几层不同需求踩不同方案。我实际用过三种第一种是直接用 QEMU 自带的 virt 平台。这是 QEMU 团队维护的通用虚拟平台启动快、设备齐全virtio 网卡、virtio 块设备、串口、RTC 都有不需要任何真实板级硬件描述最适合跑 Linux 用户态应用和验证内核功能。缺点也很明显它不是某款真实芯片的行为级模拟跑出来的性能不代表真实 SoC 的性能。第二种是针对特定芯片的模拟比如支持全志 D1C906 核心或者一些开发板的 machine。这种方案能更接近真实芯片的设备树和外设布局但 QEMU 对每种开发板的支持成熟度参差不齐经常遇到设备驱动不匹配的问题。如果你做的 AI 芯片基于某种公开的 RISC-V 核可以找找看有没有对应的 QEMU machine能省不少事。第三种是自己动手扩展 QEMU给自定义的 RISC-V 核和 AI 加速器写设备模型。这是芯片公司的常规操作——硬件 RTL 还没冻结软件仿真模型先上 QEMU。这种做法门槛高但价值也最大。我做实验台选的是第一种virt 平台。原因很直接我要验证的不是某个具体芯片的驱动而是 RISC-V 向量扩展RVV在 AI 推理场景下的软件栈是否跑得通。virt 平台对 RVV 的支持非常干净没有多余的外设干扰非常适合做算法验证。2.2 对 AI 芯片来说RVV 指令集才是灵魂聊 RISC-V AI 芯片绕不开 RVVRISC-V Vector Extension。哪怕是入门的人也应该明白AI 计算本质是大量的矩阵乘法和张量运算这些操作天然适合向量化。ARM 那边有 NEONx86 那边有 AVXRISC-V 这边就是 V 扩展。一个支持 RVV 1.0 的核配上合适的编译器跑起卷积和矩阵乘法来效率能拉开好几个档次。我搭实验台时特别确认了一件事QEMU 里模拟出来的 CPU 是否启用 V 扩展。这直接决定了后续能不能在模拟器里跑向量优化的算子。QEMU 模拟器在 CPU 类型上做得很灵活可以通过-cpu rv64,vtrue这类参数打开向量扩展甚至可以设置 vlen向量寄存器长度。这一点对 AI 芯片实验台来说比模拟多少个核还重要。我见过不少人栽在这里——拿默认参数启动 QEMU进去后/proc/cpuinfo里根本没有riscv,isa的 V 标志然后编译任何用到向量指令的代码都会报非法指令错误。这不是模拟器的问题是你没把 vector 开关打开。2.3 AGENT 在这个方案里的真实定位说完 QEMU 和 RISC-V再聊 Agent 的角色。我这次用的是个大模型驱动的 Agent 工作流它做的事情包括根据我给的硬件目标RISC-V 64 位 RVV生成编译内核的 defconfig 修修补补方案分析 QEMU 启动卡住的日志定位是设备树问题、驱动问题还是 rootfs 问题帮我写 buildroot 配置、写测试用例、生成性能基准脚本。说白了Agent 不是来替我做决定的而是当读过很多文档的助手来用的。它最大的价值是省去了我在文档海洋里捞信息的时间。QEMU 的文档、RISC-V 内核的 Kconfig、buildroot 的配置项这些内容的细节多到一个人根本记不住让 Agent 先梳理一遍我再做判断效率翻倍。这里我建议你把 Agent 当资深搜索 代码助手的组合体不要当权威。它给的命令和配置你仍然要自己验证但用好了确实能少掉大部分头发。3. 环境搭建实操从零拉起 QEMU RISC-V 虚拟硬件3.1 安装 QEMU源码编译还是包管理器我建议各搞一套QEMU 的安装有两条路线直接用系统包管理器装或者源码编译。我强烈建议两条都走。包管理器的版本胜在稳定、装完即用。在 Ubuntu 上就是一条命令sudo apt install qemu-system-misc注意不是qemu-system-riscv64单独一个包很多发行版把非 x86 架构的模拟器都塞进了qemu-system-misc。装完验证一下qemu-system-riscv64 --version如果输出正常说明基础版本到位。但这里有个问题发行版的 QEMU 通常版本偏旧对 RVV 1.0 的支持可能不完整或者缺少一些新加入的特性。所以我会同时从源码编译一个最新版作为实验台的主力模拟器。源码编译 QEMU 并不难但有几个坑值得先说依赖库除了 build-essential还需要 ninja-build、pkg-config、libglib2.0-dev、libpixman-1-dev配置时用--target-listriscv64-softmmu可以只编 RISC-V 系统模拟器编译时间骤降最好加--enable-slirp后面配置网络要用。命令大概是这样git clone https://gitlab.com/qemu-project/qemu.git cd qemu mkdir build cd build ../configure --target-listriscv64-softmmu --enable-slirp make -j$(nproc)编译完成后build/qemu-system-riscv64就是我们的主力工具。我实测下来源码编译的版本比系统自带的版本对向量扩展的模拟更完整启动速度差异不大。3.2 交叉工具链没有它你在虚拟平台上什么都编译不了QEMU 只是硬件模拟器你还需要一套能在 x86 宿主机上生成 RISC-V 可执行文件的交叉编译工具链。没有工具链你连一个 hello world 都跑不到目标平台上。有三条路可以走用发行版自带的交叉工具链。Ubuntu 下装gcc-riscv64-linux-gnu然后直接用riscv64-linux-gnu-gcc编译用 buildroot 自己编一套工具链好处是版本可控、glibc/musl 可选直接下载 Sifive 等团队提供的预编译工具链。我推荐 buildroot 路线原因在于后面做 rootfs 也要用到它一条链路全搞定。buildroot 本身是个极其强大的嵌入式 Linux 构建工具它能生成完整的交叉工具链、内核、rootfs。下载解压后make qemu_riscv64_virt_defconfig然后如果你不需要特别定制直接make。注意第一次编译时间会比较长因为要从零编译工具链大概 20 到 40 分钟取决于机器性能。编完后output/images/目录下就有完整的启动镜像包括Image内核、rootfs.ext2、fw_jump.elfOpenSBI等。如果你只是想快速验证一下交叉编译好不好使可以先用发行版工具链做个最小测试cat hello.c EOF #include stdio.h int main() { printf(hello riscv\n); return 0; } EOF riscv64-linux-gnu-gcc -static -o hello hello.c file hello输出显示ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV)就对了。static 编译是为了避免目标平台上没有动态库的麻烦。3.3 内核配置这一步决定实验台能不能跑 AI 负载拿到一根能跑的 RISC-V Linux 内核只是起点。要让它成为AI 芯片实验台的内核我必须打开一堆和向量扩展、性能监控、AI 加速相关的配置项。我的做法是先以defconfig为基础然后手动改几个关键选项make ARCHriscv CROSS_COMPILEriscv64-linux-gnu- defconfig make ARCHriscv CROSS_COMPILEriscv64-linux-gnu- menuconfig在 menuconfig 里重点检查这几项CONFIG_RISCV_ISA_V必须打开这是内核支持 RVV 向量扩展的总开关。内核编译本身不一定需要向量扩展但运行时访问向量寄存器需要内核正确保存恢复上下文CONFIG_FPU一般默认开但确认一下没错CONFIG_VIRT_DRIVERS和CONFIG_VIRTIO_PCIvirtio 设备驱动QEMU 虚拟 IO 的关键CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT系统启动时自动挂载 /dev没有它容易出现启动后设备节点缺失的问题。还有一个容易忽略的——CONFIG_STRICT_KERNEL_RWX。这个选项在部分 QEMU 机器上会和某些版本的 OpenSBI 有兼容性问题如果启动到一半突然死机可以先关掉试试。配置完成后编译内核make ARCHriscv CROSS_COMPILEriscv64-linux-gnu- -j$(nproc)编译产物是arch/riscv/boot/Image一个扁平的内核镜像QEMU 直接认这种格式。如果想用 U-Boot那就需要Image.gz或者 vmlinux但 virt 平台可以绕过 U-Boot 直接启动省一层麻烦。3.4 rootfs别再用 busybox 糊弄了跑 AI 框架需要完整环境如果你只是启动内核看个 shellbusybox 根文件系统就够了。但要跑 Python、PyTorch、ONNX Runtime 那套东西busybox 完全不现实——它连 glibc 的动态链接都支持得不利索更别说 Python 解释器了。我这次用的是 buildroot 生成的 rootfs然后在上面额外塞东西。buildroot 的qemu_riscv64_virt_defconfig默认生成的rootfs.ext2自带 busybox 和一些基础工具作为一个地基非常好用。接下来你要做的是把交叉编译好的 Python 和依赖全部塞进去。这个过程比较折腾我后面专门讲。另外提一句buildroot 里其实可以勾选 Python3、PyTorch 等包在Target packages→Interpreter languages和Libraries菜单里但 PyTorch 这种重框架在 buildroot 里的支持不一定完整版本也可能滞后。我采取的方案是buildroot 只管系统环境和基础库然后手动交叉编译 AI 框架做精细控制。4. 关键一步让 Agent 帮你搞定繁琐的配置与排错4.1 我如何给 Agent 分配任务整个环境搭建最大的痛点不是某个单独的技术难而是步骤多、易错点分散。Agent 在这里特别擅长做信息的收集和整合。我的用法是这样的首先我把目标描述清楚使用 QEMU 的 virt 机器启动一个 RISC-V 64 位、支持 V 扩展的 Linux 系统rootfs 是 buildroot 生成的内核需要支持 virtio、ext4 和网络。请生成完整的启动脚本。然后Agent 会给我一份可执行的 QEMU 命令包含-machine virt、-cpu rv64,vtrue、-kernel Image、-drive filerootfs.ext2,formatraw,idhd0、-device virtio-blk-device,drivehd0、-netdev user,idnet0、-device virtio-net-device,netdevnet0这些关键参数。虽然这些参数我大致都知道但让它一次性生成完整命令节省了回忆和查 man page 的时间。更值钱的是排错环节。启动过程经常遇到内核 panic、设备树解析失败、文件系统挂载失败这些日志又臭又长。我把日志丢给 Agent让它帮我定位是哪个设备驱动出了问题应该查哪个内核配置项。这比自己在几千行日志里 grep 效率高得多而且效果不差——因为 QEMU 的常见问题在公开资料里都有答案Agent 已经完全读过这些资料。4.2 Agent 生成启动脚本的复盘下面是我和 Agent 协作后的最终启动脚本经过了我的修改可以直接用qemu-system-riscv64 \ -M virt \ -cpu rv64,vtrue,vlen128 \ -smp 4 \ -m 4G \ -kernel Image \ -drive filerootfs.ext2,formatraw,idhd0 \ -device virtio-blk-device,drivehd0 \ -netdev user,idnet0 \ -device virtio-net-device,netdevnet0 \ -append root/dev/vda rw consolettyS0 \ -nographic逐条拆一下-cpu rv64,vtrue,vlen128打开向量扩展向量寄存器长度 128 位。这是实验台能不能做 AI 计算的关键我踩过坑之后每次都会确认这个参数-smp 44 个虚拟核。虽然 QEMU 的 SMP 是模拟出来的但对于跑多线程推理负载、验证并行性能基线有意义-m 4G4G 内存。跑 PyTorch 这类框架2G 以下会非常局促-device virtio-blk-device,drivehd0virtio 块设备。我特意不用-drive ifvirtio那种老写法显式指定 device 类型更清晰-netdev user,idnet0-device virtio-net-device,netdevnet0用户态网络虚拟机能通过宿主机的网络栈访问外网不需要额外的网卡设备权限-nographic纯串口控制台不走图形界面方便在 SSH 会话里操作。启动成功的标志是串口输出到buildroot login:然后就能通过 root 账户默认无密码登录系统。进去后第一件事cat /proc/cpuinfo看到isa : rv64imafdcv或者类似包含v的字符串就说明向量扩展生效了。4.3 让 Agent 生成 AI 验证用例矩阵乘法和向量汇编实验台立起来之后光能开机不算完得证明它真能跑 AI 相关负载。我让 Agent 生成了一套验证用例分三个层次。第一层是向量指令功能验证。直接在 C 里嵌入向量汇编算一个简单的向量加法。用 RVV 的汇编能直观地确认 CPU 的向量单元工作正常#include stdio.h int main() { int v1[4] {1, 2, 3, 4}; int v2[4] {5, 6, 7, 8}; int v3[4] {0, 0, 0, 0}; asm volatile ( vsetivli zero, 4, e32, m1, ta, ma\n vle32.v v0, (%0)\n vle32.v v1, (%1)\n vadd.vv v2, v0, v1\n vse32.v v2, (%2)\n : : r(v1), r(v2), r(v3) : memory ); for (int i 0; i 4; i) { printf(%d , v3[i]); } printf(\n); return 0; }编译时注意加-marchrv64gcv不然编译器不知道目标 CPU 支持向量指令riscv64-linux-gnu-gcc -marchrv64gcv -static -o vec vec.c在虚拟机上跑出6 8 10 12就说明向量存储和计算链路是通的。第二层是经典矩阵乘法。用纯 C 写一个 256x256 的矩阵乘作为一个性能基线。第三层是装 Python 和 PyTorch跑一个 MobileNet 或者 ResNet 的分类推理这是最接近真实 AI 芯片负载的验证。后面我会单独讲 PyTorch 的交叉编译这是整个实验台搭建里最掉头发的一步。5. 在虚拟实验台上跑 AI 框架PyTorch 的交叉编译与部署5.1 为什么不能直接 pip install很多人在这一步会天真地以为进到 RISC-V 虚拟机的 Linux 里就能直接 pip install torch。结果是惨不忍睹的——PyTorch 的官方 pip 包根本没有 RISC-V 的预编译 wheelpip 会尝试从源码编译然后因为缺少各种依赖或者编译器不支持特定指令集而失败。正确做法是交叉编译或者用第三方维护的构建脚本。RISC-V 社区其实有人专门做这件事比如riscv-software-src下面就有针对 RISC-V 的工具链支持和部分软件包维护。但我实测下来最可靠的方式是在宿主机上用交叉编译链把依赖全部编译成 RISC-V 版本然后拷进虚拟机的 rootfs 里。这个方案的依赖链条很长OpenBLAS做底层矩阵运算、Python 3.x、NumPy、PyTorch 自身。每一步交叉编译都可能出幺蛾子也是 Agent 发挥作用的地方。5.2 编译 OpenBLAS 做底层加速PyTorch 在 CPU 上的性能很大程度上依赖 BLAS 库。对于 RISC-VOpenBLAS 有相对成熟的移植支持 RVV。交叉编译命令大致如下git clone https://github.com/xianyi/OpenBLAS cd OpenBLAS make CCriscv64-linux-gnu-gcc \ HOSTCCgcc \ TARGETRV64G \ CFLAGS-marchrv64gcv -O2 -fPIC \ -j$(nproc)注意TARGETRV64G很重要OpenBLAS 需要知道你编译的目标架构才能选择正确的 kernel。编完后会生成libopenblas.a和libopenblas.so后续编译 PyTorch 时指定这个库的路径。这块我踩过坑OpenBLAS 默认会检测宿主机的 CPU 并生成对应的优化 kernel交叉编译时必须显式指定TARGET否则编出来的库在 RISC-V 上根本跑不起来。Agent 第一次给我的命令就把TARGET漏了编译出来的库一测就崩排查半天才发现。5.3 交叉编译 Python 与 NumPyPyTorch 的交叉编译极其复杂我的建议是分两步先用 buildroot 辅助生成一个基础 Python然后用宿主机交叉编译 PyTorch 时链接到这个 Python 的共享库上。我自己反复试过很多次最终选了这么一条更省力的路直接在 buildroot 里勾选 Python3 和 PyTorch 相关的选项。虽然版本可能不是最新的但 buildroot 把交叉编译的依赖问题全部处理好了。配置菜单路径是Target packages→Interpreter languages→python3以及Target packages→Libraries→pytorch。当然buildroot 的 PyTorch 包有时候编译不过去尤其是新版 buildroot 对 PyTorch 的依赖处理和上游版本更新之间存在时间差。如果你遇到编译失败Google 一下 buildroot 邮件列表或者 issue tracker通常有人已经给出 workaround。实在不行就换一个版本的 buildroot或者退回用宿主机交叉编译。5.4 实操验证在 RISC-V 虚拟机上跑一次推理把编译好的 Python PyTorch 拷贝进虚拟机的 rootfs 后我写了一个最小化的推理验证脚本import torch import torch.nn as nn class SimpleNet(nn.Module): def __init__(self): super().__init__() self.fc nn.Linear(8, 2) def forward(self, x): return self.fc(x) model SimpleNet() x torch.randn(1, 8) y model(x) print(y)在虚拟机上运行python3 test_torch.py看到正常输出一个[1, 2]形状的 tensor 就说明 PyTorch 已经可以在 RISC-V 实验台上跑起来了。这个验证的意义在于它证明了你手上的这套 QEMU 模拟环境已经具备了作为 AI 芯片软件栈开发平台的基本能力。后续你想验证新算子、调试量化算法、测试编译器的向量生成能力都可以在这个环境里做。6. 常见问题与排查技巧实录6.1 启动卡住串口没有输出最常见的现象是qemu-system-riscv64跑起来后终端一片空白既不报错也没有任何输出。优先怀疑三个点内核参数没写consolettyS0。RISC-V virt 平台的标准控制台是串口不指定的话内核不知道往哪输出缺少-bios参数。如果你没有提供 firmware需要确保 QEMU 能找到默认的 OpenSBI。如果用源码编译且没装 OpenSBI可以先用-bios none跳过固件直接启动内核很多情况下这是最快的排除方法内存太小导致内核解压失败。给 512M 以下内存跑现代 RISC-V 内核很容易在早期就挂掉建议至少 1G 起步。6.2 报错guest has not initialized the display这个通常是因为没加-nographic但又没有图形界面环境。解决办法就是明确用-nographic模式跑并且去掉所有 display 相关参数。6.3 rootfs 挂载失败VFS: Unable to mount root fs几乎都是 root 设备名对不上。QEMU virt 平台的 virtio 块设备在 Linux 里是/dev/vda如果你写的启动参数是root/dev/sda那就必然挂载失败。另外确认一下 rootfs 的镜像格式buildroot 生成的.ext2用formatraw即可但如果你自己做了 ext4 之类的变更QEMU 的 drive 参数也要对应调整。6.4 进入系统后不能联网-netdev user模式默认就带 DHCP 和 NAT但不代表虚拟机内部一定会自动配置网卡。进去后先确认有没有eth0设备ip link如果没有多半是内核没有编入 virtio-net 驱动。检查一下CONFIG_VIRTIO_NET是否打开以及CONFIG_VIRTIO_PCI。设备树能识别到设备但内核没有对应驱动的话lspci一样看不到。6.5 向量指令执行报 Illegal Instruction要么是 CPU 参数没加vtrue要么是编译器生成的指令超出了目标支持的版本。注意旧版 QEMU 可能只支持向量扩展草案而不是 1.0 最终版如果你的编译器默认生成 1.0 指令就可能出现非法指令。解决办法是升级源码版 QEMU并确保-cpu参数正确开启 V 扩展。6.6 Agent 给的命令报错怎么办这是我最想强调的一点现在用 Agent 搭环境的人越来越多但 Agent 给你的命令并不总是对的。遇到报错不要慌也别直接换下一个命令——把报错信息原封不动地喂回给 Agent它会自我修正的。实际上Agent 帮我解决的最难一个问题就是为什么 OpenBLAS 交叉编译后在 RISC-V 上 segfault。7. 实验台的扩展方向从模拟到接近真实芯片既然这个题目叫AI 芯片的实验台那它不能只是一个能跑 Linux 的 QEMU 虚拟机。我觉得至少要往这几个方向扩展才能名正言顺地当实验台用。第一个方向是接入自定义加速器模型。QEMU 支持通过 QOMQEMU Object Model添加自定义设备。如果你有自己设计的 AI 加速器 RTL 或者 C 模型可以把它封装成 QEMU 设备挂到 virt 平台上。这样软件工程师可以提前写驱动编译器团队可以验证自定义指令的生成整个软件栈不需要真实硬件就能跑通。第二个方向是精确的性能建模。QEMU 默认是功能模拟不模拟时序所以你测到的性能跟真实芯片差距很大。要做准确的性能基线需要给 QEMU 加周期级别的模拟能力。QEMU 社区已经有一些 patch 在做这方面的工作比如在模拟器中插入计时器和缓存模型但成熟度还不够。如果你是认真做芯片软件优化的可能需要研究一下。第三个方向是把实验台接上持续集成。QEMU 是命令行工具非常适合跑自动化测试。我建议把整套环境封装成 CI 脚本每次代码变更自动启动 QEMU、跑测试用例、生成报告。RISC-V 社区很多项目就是这么干的——你提交一个代码CI 系统里的 QEMU 就会拉起一个虚拟机帮你跑测试矩阵。我自己目前的扩展计划是这样的第一步先把 RVV 1.0 的完整测试套件跑起来我指的是 RISC-V 官方维护的riscv-tests里的 vector 测试用例。第二步是把一个轻量级的 YOLO 检测模型用 ONNX Runtime 跑起来看看整个推理链路还缺什么。第三步是尝试在自己的 QEMU fork 里挂一个简单的硬件加速器模型验证软件栈的可扩展性。8. 写在最后的几个建议如果你打算照着这篇文章的思路搭自己的实验台我个人的经验是不要先追求大而全。一开始就跑 PyTorch 非常容易劝退自己因为交叉编译的坑太多每一个坑都能耗掉你一个晚上。我建议的路径是先把 QEMU 启动到控制台这一步必须走通它验证了你的工具链、内核配置和 rootfs 是基本没问题的。然后加一个简单的 C 向量程序确认 RVV 生效。再往后用 buildroot 一点点把 Python 环境和依赖加进去每加一个依赖就测试一次不要攒一堆问题再排查。关于 Agent我的体会是它最大的价值不是给你一个完美答案而是在你手足无措时给你一个合理的下一步。很多 QEMU 和 RISC-V 的问题在网络上有零散的回答Agent 能把这些信息聚合起来变成可执行的命令。但你依然需要理解这些命令背后的原理——真要排查问题的时候还是得回到文档和源码里去。最后分享一个小技巧给 QEMU 加上-d guest_errors参数再启动在排错阶段能看到很多被吞掉的错误信息。这个参数我几乎每次调试都会带帮我定位过设备树错误和内存映射冲突是目前我找到的性价比最高的 QEMU 调试参数。这套实验台搭好之后接下来的 AI 芯片软件栈相关工作我都打算在这个环境上做了。