最近在折腾RISC-V AI芯片的验证工作说实话开发板就那么一两块调试起来还得轮流排队。于是我把主意打到了QEMU上——用软件模拟出一整个RISC-V SoC把AI加速器相关的功能也挂上去这样就能随时拉起一个实验台跑指令集测试、跑小模型推理。更妙的是这次搭建我没怎么手动敲命令全程让AGENT替我干。这篇文章就把完整过程和踩过的坑聊透适合想快速获得一块RISC-V AI实验环境但又不愿深陷命令行泥潭的开发者。1. 项目概述与思路拆解1.1 为什么选择QEMU模拟RISC-V AI芯片直接买一块带AI加速器的RISC-V开发板动辄几千上万而且供货周期长想多人共享更是麻烦。QEMU这种纯软件模拟方案只要宿主机配置够用就能同时拉起多个虚拟机每个虚拟机都像独立的芯片环境快照、回滚、断点调试都极其方便。说白了它就是一块不需要等快递、不会烧板子的“虚拟开发板”。更重要的是QEMU对RISC-V的支持已经相当成熟。它不仅能模拟通用ISA指令集还能通过启动参数开启V向量扩展这个扩展正是AI计算落地在RISC-V上最常用的指令集加速手段。很多工业级的AI算子库比如基于RVV的矩阵乘法、卷积运算都能在QEMU里真实跑起来。对于验证指令集正确性、跑通编译工具链、评估算子性能这个实验台完全够用。AI芯片的另一个关键特征是异构计算。真实的AI芯片里通常包含CPU核、NPU核、DSP核甚至专用加速器。QEMU不直接模拟一颗完整的NPU但它可以通过挂载不同的虚拟设备比如virtio-gpu、virtio-net以及自定义的mmio设备来模拟外设交互路径。再加上如果有GDB调试配合就能观察CPU与设备之间的握手过程。对我这种做系统软件的人来说这套环境的价值相当高。1.2 AGENT在环境搭建中承担哪些工作传统环境搭建全是手工活查文档、装依赖、编译内核、配网络、调环境变量一套下来没两三天搞不定。这次我换了一种思路让AGENT来做这个脏活。它可以理解我的自然语言指令自动生成shell命令、分析报错日志、修改配置文件。我只需要给出目标比如“启动一个带网络功能的RISC-V虚拟机”它就会分步执行并把关键输出反馈给我。实际操作中AGENT能做的核心事情有三件。第一是环境探测它先跑一条命令检查QEMU是否安装没有就自动安装有就验证版本。第二是脚本生成根据虚拟机的目标功能给出一套完整可运行的QEMU启动参数并把参数拆解成可维护的Shell脚本。第三是错误修正当启动失败它会读日志、定位问题、给出修复建议然后继续执行直到进入系统。可以说AGENT相当于一个经验丰富的调参助手。它能记住前后文不会像无头苍蝇一样反复试错。尤其是面对QEMU这种参数极多、选项极碎的工具AGENT能很快把合适的参数组合从记忆里调出来省去大量搜索引擎来回切换的麻烦。1.3 这个实验台最终能跑什么内容搭建完成之后这台“虚拟芯片”能做的事情不少。最基础的是启动一个完整的Linux发行版可能还需要路由器才能访问网络减少宿主配置的干扰。然而为了稳妥我还是选择了常见的方式给虚拟机添加一个用户态网络默认支持NAT这样虚拟机里的访问计就自动放到NAT后面相应的SDK在里面作互通测试。如果你对底层更感兴趣也可以在QEMU里通过SDK利用共享内存支持并定义固件参数。通过串口控制台你能看到Linux内核启动的全过程从bootloader、设备树初始化到文件系统挂载。这在真实芯片上通常需要外加调试器才能看到而在QEMU里就是换个参数的事。对于AI验证我计划做两层测试。第一层是跑通Python和PyTorch用简单的卷积验证RVV向量加速是否生效第二层是编译一些RISC-V的裸机程序模拟片上的AI计算流程。当然如果有tensorflow lite这样的框架也可以试着交叉编译再移植进虚拟机在CPU上做推理测试。2. 环境准备与QEMU安装2.1 宿主机选择与基础软件QEMU是跨平台的Linux、Windows、macOS都能跑。但我在实际体验中还是最推荐Linux作为宿主机尤其是Ubuntu 20.04或22.04因为编译工具链和网络配置都更顺手。如果你主力机器是Windows先装一个WSL2再继续也完全可以我这次就是在WSL2的Ubuntu 22.04里面完成的。宿主机内存至少需要8G因为虚拟机会占去至少4G。磁盘空间建议预留30G以上一个基础镜像解压出来就要几个G再加上要装Python环境和AI库10G打底。CPU则不强求模拟RISC-V的速度本来就比原生慢能多核就多核QEMU支持多线程模拟性能会好不少。在动手之前先把基础工具装好build-essential、git、curl、wget、ninja-build。这些都是编译依赖后续无论是装qemu还是构建工具链都用得到。记住一条经验不要在裸系统上直接就装qemu最好先把系统源更新一遍避免旧源坑人。2.2 安装QEMU RISC-V支持安装QEMU的方式有两种直接用包管理器或者编译源码。如果只是体验一下apt install qemu-system-misc是最快的它包含各种非x86架构的模拟器其中就包括qemu-system-riscv64。但这样装的版本通常偏旧可能缺失V向量扩展等关键特性。所以我推荐老老实实编译最新版。先到QEMU官网下载最新的源码压缩包然后解压、创建build目录在build里执行configure。这里有个关键的configure参数叫--target-list一定要明确指定riscv64-softmmu。只编译这一个目标能节省大量时间和磁盘空间。加上--enable-debug可以在以后调试QEMU本身时用到。配置完成后make -j4我的机器上大约需要30分钟。完成后在build目录下会生成qemu-system-riscv64这就算编译好了。我习惯把它链接进/usr/local/bin这样后续写脚本就不需要写完整路径。测试一下无参数运行如果没有报错说明基础环境没问题。2.3 准备RISC-V系统镜像要让虚拟机跑起Linux系统光有QEMU还不行还需要一套RISC-V架构的内核和根文件系统。最省事的方法是直接下载官方做好的SDK镜像Ubuntu和Fedora都提供RISC-V版本而且支持rootfs。下载回来的就一个镜像文件比如ubuntu-24.04-server-riscv64.img可以直接作为块设备交给QEMU启动。不过启动前需要确认两点内核单独有vmlinuz和initrd文件还是都打在磁盘里。我习惯用fedora官方提供的fw_payload或者Ubuntu的裸内核因为它们的启动参数简单只要告诉QEMU内核文件和根目录设备即可。如果只有一个磁盘镜像可以通过-fsdev local参数把它当作九组件共享文件夹另一种方式就是将整个镜像直接作为virtio-blk设备挂载。拿到镜像之后还需要准备OpenSBI固件这是RISC-V架构特有的Bootloader。QEMU自带的opensbi版够用不加参数即可自动启动。关键是将virtio的磁盘识别为设备名/dev/vda所以root参数要写成root/dev/vda2具体分区编号要看镜像内部的分区表可以用fdisk -l查一下。3. AGENT辅助搭建核心配置3.1 生成并执行QEMU启动参数AGENT在理解了我的需求后很快给出了一个QEMU启动命令行。它的最佳优势是能免去我手写大片命令行参数。通常会用这样一行命令qemu-system-riscv64 \ -machine virt \ -cpu rv64,vtrue,vlen256 \ -smp 4 \ -m 4G \ -kernel ubuntu-riscv64/vmlinuz \ -initrd ubuntu-riscv64/initrd.img \ -append root/dev/vda1 rw consolettyS0 \ -drive fileubuntu-riscv64/ubuntu.img,formatraw,ifvirtio \ -nographic注意-cpu rv64,vtrue,vlen256这里vtrue表示启用RVV向量扩展vlen256设置向量长度这非常关键。如果你看到后面程序运行时报“Illegal instruction”有很大概率就是这里没配置正确。另外-smp 4和-m 4G分配资源要适中QEMU模拟器本身也要吃内存给得太多反而容易触发宿主机内存不足。AGENT在生成这个命令后还特意说明 -nographic 会把串口作为控制台这样就不需要额外的图形窗口本地跑起来特别稳。如果不加这项QEMU会弹出一个GTK窗口在纯命令行环境里必出差错。一个小的技巧是第一次启动之前先用-panic-safe参数测试内核加载再进入正式主流程。3.2 配置网络让虚拟机联网默认方式是用QEMU的用户态网络也就是说在QEMU启动参数里加上 -netdev user,idnet0 -device virtio-net-device,netdevnet0。这种方式的好处是无需管理员权限即可让虚拟机访问外部网络适合联网安装软件包。需要提醒的是在NAT模式下虚拟机并不能被宿主机之外的装置直接访问但做AI环境测试完全足够。如果你需要更高级的网络拓扑比如让虚拟机挂到一个tap0设备上那就需要用AGENT生成脚本来管理员权限给宿主创建tun设备再配置桥接。个人建议刚开始不要碰tap纯自虐一个IP冲突就能折腾一小时。我们先保证能访问标准储存库等系统起来了再来调整网络。在虚拟机里配置网络之前先运行一下 ip addr通常能看到eth0已经激活并自动通过DHCP获得了10.0.2.15这样的地址。如果卡住了AGENT通常会建议检查宿主机是否开了防火墙或者QEMU自设的DNS服务器是否有问题。根据实际总结百分之八十的情况都是忘了把-netdev参数加到启动脚本里。3.3 挂载AI加速器模拟设备虽然QEMU里并没有一个现成的NPU设备供你switch成on但可以把它集成到自己的virtio_gpio和vhost_user框架中。AGENT帮我把虚拟根FS里的驱动模块编译好然后把文件系统打包成sd文件挂载到运行中的虚拟机上。具体做法是用virtio-blk把自定义的镜像分区挂载为/dev/vdb然后手动mkdir mount到某个指定路径。更贴近AI计算的是直接在板上模拟一个MMIO设备利用设备树平台描述向Linux内核注册一个虚拟加速器节点。虽然这需要C语言写内核模块但目标是在QEMU里看到仿真“AI芯片”的侧面效果。AGENT可以生成一段具体的设备树片段说明soc中的某个寄存器地址映射到该加速器。在上层通过简单的用户态程序申请mmap映射就能看到中断、DMA交互。在缺少硬件真机之前用软件建模来提前验证基础框架是合理选择。比如用一个通用中断控制器硬件连接CPU当一个虚拟中断触发后内核会调用对应的中断回调函数这和真实芯片上IRQ处理路径一致。4. AI开发环境搭建与验证4.1 在虚拟机内安装Python与PyTorch成功登录系统后第一件事就是换源国内Ubuntu可以把软件源切成镜像省得拉包速度慢到怀疑人生。然后安装python3-pip、python3-venv以及编译AI依赖所需的libopenblas-dev这是后序构建numpy等库的基础。PyTorch官方并没有提供RISC-V版本的预编译wheel所以最稳妥的方式是用pip直接安装如果版本不支持就退而求其次安装tensorflow lite。我实测下来在RISC-V的QEMU上跑一个极小型的线性回归脚本问题不大但涉及图像分类的ResNet可能需要好几分钟。还是要记住这只是验证环境不是性能测试工具。AGENT在处理这个过程时先检查了openblas是否存在然后自动把虚拟环境激活安装pytorch并加入镜像库下载大幅节省时间。它生成的一个关键建议是不要用系统python安装包否则会随即覆盖依赖导致内核模块编译失败。4.2 编写并运行一个简单AI样例为了验证RVV向量加速是否被调用我写了一个矩阵乘法的小脚本使用PyTorch的矩阵乘法并开启对向量的支持标记。同时对比关闭向量扩展时耗时再看一眼空闲时是否有恢复提示。说实话QEMU下的性能差异并不可观因为模拟器本来就会打折扣但能确认CPU配置的向量长度是否符合预期。也可以尝试用torchvision载入一个预训练的轻量模型如MobileNetV2对一副小的随机噪声图像做分类推理。因为下载预训练权重还需要联网网络如果没配好会卡在下载步骤。所以我在虚拟机里提前下载好权重的原始地址然后用内置下载器获取。运行起来后虽然预测无意义流程却是完整的。同样值得尝试的是RVV原语编程就是直接用intrinsic代码写一段点积再编译运行。这个方法更底层的验证了工具链里riscv64-linux-gnu-gcc是否支持向量扩展。这类写死在代码中的指令对照汇编可以发现是否输出了vsetvli类的指令只要看到说明CPU和编译器都已经准备就绪。4.3 性能优化与资源限制QEMU模拟性能远低于原生执行这是通病但也有些日常优化手段。比如分给虚拟机的CPU数量不要超过物理线程一半因为QEMU的TCG模式需要大量宿主机CPU资源来翻译指令。更有效的办法是使用KVM加速但RISC-V的KVM还需要要硬件支持一个月前的内核版本可能还不成熟建议暂时放弃。网络也是一个瓶颈阶段用户态NAT模式最大也就几百Mbps更别说跨架构模拟的开销。为了让包传输尽量快我直接把AI的预训练模型权重和Python包安装在同一个磁盘镜像里避免再太多的下载与服务。下一步可以利用QEMU的savevm冻结镜像再做针对性微调回滚非常干净。内存方面虚拟机分配4G看似很大其实在编译PyTorch依赖时还是会爆例如编译cpp扩展时所需的临时文件会使用大量内存。解决方式是给虚拟机加一个8G的swap文件用dd创建稀疏文件再用mkswap和swapon启用非常解压。5. 常见问题与排查技巧5.1 QEMU启动报错的快速定位如果刚命令行启动就打印错误告警信息基本有两种。一是“qemu-system-riscv64: Unsupported CPU type”这说明-cpu rv64,vtrue这个参数不在当前编译配置里。检查组一下你在configure阶段是否启用了size属性如果没有重新编译加上即可。另一种是“Could not open option rom ”大多由文件路径或目录权限引起查看bash脚本里所有路径是否以绝对路径开头。有一些容易误踩误导提示。像“virtio-net-pci unsupported”可能是缺少PCIe设备支持但RISC-V的virt机器常用的是virtio-net-device不是PCI。请把启动参数拉在里对照目标架构的推荐模板不要盲目从x86的文章里粘贴。遇到黑屏多半是串口没有绑定加上-nographic后要确认内核信息输出。在定义console参数时务必写成ttyS0而不是tty0这个错误我在最开始犯过结果只能在图形窗户里瞎点。5.2 网络通信失败的解决办法最常见的问题是虚拟机里能ping通网关但域名解析失败。因为NAT的DNS服务默认是10.0.2.3如果你在启动参数里改了-user或-netdev很可能会覆盖DNS。给-append加上nicttyS0后在virtual console里运行sysctl net.ipv6.conf.all.disable_ipv60也许能恢复DNS解析。如果还不行就直接手动在/etc/resolv.conf写公共DNS。另一个尴尬场景虚拟机刚启动时网络可用跑包跑几分钟后突然断流。这多半是Windows WSL2的NAT表溢出尤其是长时间运行SSH后。处理方式是在宿主机执行wsl --shutdown然后重新打开WSL2再启动虚拟机。切记虚拟机未关闭时不要直接WSL2重启否则镜像可能损坏。如果AGENT在虚拟机里检测到网络请求超时它会自动生成一组iptables规则来开放端口和转发部分流量。当然这里指的是个别流量绕过涉及默认安全策略的取舍我只开放了需要使用的端口并严格分包。5.3 AGENT中途执行崩溃的恢复办法AGENT在处理长命令时偶尔会返回“agent execution terminated due to error”尤其是遇到镜像仓库连接超时或磁盘满了。但我发现这是可以预防的大型编译任务之前先df -h确保有5G以上空间如果仅有剩余不够就用qemu的qcow2镜像动态扩容或者直接在宿主机调整磁盘分区。另一种情形是AGENT从某个脚本中途挂起这是由于命令里有交互式输入比如apt安装y确认或vi编辑器。最好要求AGENT输出所有命令前附加一个可解析参数例如DEBIAN_FRONTENDnoninteractive和环境变量CI1。这样诸多交互式提示都会跳过去配合set -e则能保证失败即退出不让它在泥潭里越陷越深。既然AGENT能在失败后继续执行真正宝贵的恢复方法是利用QEMU的磁盘快照功能。在启动的时候给指标加一个qcow2格式的overlay这样如果执行彻底坏掉直接删除这个overlay再重启就能回到上次干净的正常状态。我现在养成了习惯每完成一个重要步骤如装好PyTorch、配好网络就主动停一下并保存快照。以后再出现AGENT崩掉或者安装包搞坏依赖直接回退十几秒完事。这个实验台后续还可以继续扩展比如加进更强RVV仿真、接入真实板子的串口输出甚至做成一个多虚拟机协作的集群。只是无论如何QEMU加AGENT这套组合肯定是以后我做架构探索时的重要基石。