上一篇介绍了怎么在 QEMU 里跑起 openEuler RISC-V 虚拟机，并在 VM 里原生编译了第一个 hello world。但真正开始做 RISC-V 软件移植后你会发现：在 QEMU 模拟的 VM 里编译大软件实在太慢了（慢 10~100 倍），而且 openEuler 25.03 的发行版内核默认不开放向量扩展，跑向量程序直接 SIGILL。这篇文章记录我从"交叉编译 → qemu-user 验证 → RVV 向量踩坑 → 自编译内核"的完整进阶过程，每一步都有实测命令和踩坑记录，希望能帮你少走弯路。

先说结论：这一套流程走下来，最大的收获不是学会了某条命令，而是建立了一条**“宿主交叉编译 + qemu-user 先行验证 + VM 只跑产物”**的标准化工作流。它让我在做软件包移植验证时，把"改一次代码 → 跑一次验证"的周期从小时级压缩到分钟级，而且绝大多数正确性问题根本不需要碰真机就能暴露出来。

前置环境说明

我的环境（与入门篇相同）：

• 宿主：WSL2 Ubuntu（x86_64），Windows 侧有 Clash 代理
• 目标机：openEuler 25.03 riscv64 虚拟机（QEMU），SSH 端口 12055，用户名 linght153
• 目标机 ISA：rv64gc_zba_zbb_zbs（没有 v 向量扩展，这一点后面坑惨了我）
• 交叉工具链：gcc-14-riscv64-linux-gnu（GCC 14.3.0），sysroot 在 /usr/riscv64-linux-gnu/

核心工作流一句话：编译一律放宿主（WSL），VM 只跑编译产物。

一、WSL 交叉编译：把"编译"从 VM 搬回宿主

1.1 安装交叉工具链

# WSL (Debian/Ubuntu) 一条命令装齐：编译器 + C++ + binutils + C 库 + 调试器
sudo apt install gcc-riscv64-linux-gnu g++-riscv64-linux-gnu \
  binutils-riscv64-linux-gnu libc6-dev-riscv64-cross gdb-multiarch

# 验证版本和 sysroot
riscv64-linux-gnu-gcc --version        # gcc (Ubuntu 14.x) 14.3.0
riscv64-linux-gnu-gcc -print-sysroot   # /usr/riscv64-linux-gnu

⚠️ 坑 1：GCC 15 的 libstdc++ 内嵌向量指令。我一开始图新装了 GCC 15 工具链，结果链接 C++ 程序时静态库里的 libstdc++ 编译进了向量指令，-march 参数根本覆盖不了——交叉编译出的程序在目标机上直接 SIGILL。结论：RISC-V 交叉编译老老实实用 GCC 14，这是当前最稳的版本。

顺带一提：这套工具链是"全家桶"结构——编译器（gcc）、汇编器（as）、链接器（ld）、C 库（glibc）、二进制工具（readelf/objdump/nm/strip）缺一不可，任何一个环节缺失交叉编译都跑不通。装完后可以用 riscv64-linux-gnu-gcc -v 查看配置参数和 sysroot 路径，用 -print-sysroot 直接输出交叉根目录，后续 qemu-user 的 -L 参数和 CMake 的 CMAKE_SYSROOT 都指向它。

1.2 第一个交叉编译：-march 与 -mabi 选型

# hello.c 与入门篇一样，但这次用交叉编译器，目标平台 riscv64
riscv64-linux-gnu-gcc -march=rv64gc -mabi=lp64d -O2 hello.c -o hello

# 验证架构
file hello
# 预期输出：ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI

-march 和 -mabi 是交叉编译最容易踩坑的一对参数，我的理解如下：

选型铁律（血泪总结）：

1. -march 必须 ≤ 目标机真实 ISA（以目标机 /proc/cpuinfo 为准），写了目标没有的扩展 → 运行时报 Illegal instruction (core dumped)；
2. -mabi=lp64d 需要目标有 D 扩展（双精度浮点）；
3. 同一套 ABI 的二进制才能互相链接：-mabi=lp64d 编译的库只能被同样 ABI 的程序链接，报 relocation truncated 时先查 ABI 是否一致。

另外记住一个容易混淆的点：-march 决定"我能生成哪些指令"，-mabi 决定"调用约定和二进制兼容性"。前者错了运行时崩，后者错了链接时就崩——两者作用阶段不同，排查方向也完全不同。我踩过最冤枉的一次，就是忘了目标机 ISA 里没有 zbb，编出来的程序在 VM 上一跑就 Illegal instruction，当时还以为是编译器坏了。

⚠️ 坑 2：GLIBCXX_3.4.32 not found。第一次交叉编译 C++ 程序，拷到 VM 里一跑就报这个错。原因：GCC 14 的 libstdc++ 需要 GLIBCXX_3.4.32，而 openEuler 25.03 只有 3.4.30。解法：链接时加 -static-libstdc++ -static-libgcc（只静态 C++ 运行库，动态 glibc），之后用 readelf -d 检查 NEEDED 只剩 libm/libc/ld-linux 就对了。体积信号：静态版约 8.0M，动态版约 6.1M。

⚠️ 坑 3：链接报 R_RISCV_CALL_PLT ... may bind externally。这是 PIE 下的重定位问题，加 -no-pie -Wl,-z,notext 即可解决。

二、qemu-user：在 x86 宿主上直接跑 riscv64 程序

交叉编译完，下一步是在真机/VM 上验证吗？不用——qemu-user 能在宿主机上直接跑 riscv64 用户态程序，完全不需要 VM，也不需要真实硬件。

2.1 qemu-user 与 qemu-system 的区别

• qemu-system：全系统模拟，模拟整台机器（CPU + 内存 + 外设），可以装发行版、跑内核——入门篇用的就是它；
• qemu-user：用户态模拟，只翻译执行单个 ELF 文件，不经过目标内核。速度快、启动秒级，适合跑单元测试和做正确性验证。

qemu-user 相当于：给宿主加了一层"指令翻译器"，把 riscv64 的系统调用转发给宿主内核，
把 riscv64 的普通指令逐条翻译执行。所以程序眼里自己是 riscv64 环境，实际上跑在 x86 上。

这也是为什么 qemu-user 能绕过"内核不支持向量"的限制——它根本不加载目标内核，RVV 指令由 QEMU 翻译层直接模拟执行（下文第三节细讲）。对于只需要验证程序逻辑正确性的场景，qemu-user 比起一个完整 VM 轻量太多了。

# 安装
sudo apt install qemu-user

# 在 WSL 上直接跑刚交叉编译的 riscv64 程序
qemu-riscv64 -L /usr/riscv64-linux-gnu ./hello
# 预期输出：Hello, RISC-V!

⚠️ 坑 4：-L <sysroot> 不能省。不加 -L 直接跑会报：

qemu-riscv64: Could not open '/lib/ld-linux-riscv64-lp64d.so.1'

因为动态链接器 ld-linux-riscv64-lp64d.so.1 在交叉 sysroot 里（/usr/riscv64-linux-gnu/lib/），宿主机的 /lib 下根本没有。-L 就是告诉 qemu 去哪个根目录找动态链接器和库。

⚠️ 坑 5：别直接在宿主 shell 里 ./hello。riscv64 ELF 在 x86 宿主上跑会报 bash: ./hello: cannot execute binary file，这是预期行为，走 qemu-user 就对了。

2.2 通用验证三步走（强烈建议固化）

踩了几次"编译时没问题、上 VM 就崩"的坑后，我总结出任何交叉编译产物交付前的三步体检，缺一步都可能把有问题的二进制送到目标机上：

# ① readelf：链接体检 —— 该依赖谁、不该依赖谁
riscv64-linux-gnu-readelf -d app | grep NEEDED
# 预期：只剩 libm / libc / ld-linux；看到 libstdc++.so.6 就是漏了静态链接

# ② objdump：指令体检 —— 声称用了向量，真的编进去了吗
riscv64-linux-gnu-objdump -d app | grep -c vsetvli
# 预期：>0。为 0 说明自动向量化没生效或 -march 被覆盖

# ③ qemu-user：运行体检 —— 宿主机直接跑通（不经目标内核）
qemu-riscv64 -L /usr/riscv64-linux-gnu ./app && echo PASS

我把这三步固化成了 ~/.bashrc 里的一个函数 riscv64-check，之后每次交叉编译完一条命令完成体检。三步全绿才叫"可交付"。

三、RVV 向量验证：从 SIGILL 到柳暗花明

3.1 写一个最小 RVV 向量程序

RVV（RISC-V 向量扩展）和 x86 SSE/AVX 最大的不同：硬件向量长度（VLEN）对编译器未知，软件必须写成"长度无关"的代码。先理解几个关键词：VLEN 是向量寄存器位宽（常见 128/256 位），ELEN 是单元素最大位宽（默认 64），SEW 是当前操作的元素位宽（e32=32 位元素），LMUL 是寄存器组倍数（m1/m2/m4/m8），而 vsetvli 这条指令负责在运行时设置 SEW/LMUL 并返回本次实际处理的元素数 vl。写向量代码不像写 SSE 那样"假设寄存器是 128 位"——你必须假设任何长度都可能，用运行时查询的结果来控制循环。先看最小示例：

// vec.c —— 查询向量寄存器长度（完整可编译）
#include <riscv_vector.h>
#include <stdio.h>

int main() {
    size_t vlen = __riscv_vsetvlmax_e8m8();   // e8m8 一次能装的最大字节数
    printf("VLEN bytes: %zu\n", vlen);
    return 0;
}

编译（注意 -march 要带 v）：

riscv64-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -O2 vec.c -o vec
riscv64-linux-gnu-objdump -d vec | grep -c vsetvli   # >0 说明真的编进了向量指令

3.2 坑 6：VM 里跑向量程序直接 SIGILL（最大拦路虎）

我在 QEMU 启动参数里特意加了 -cpu rv64,v=true,vlen=256，进 VM 后 grep v /proc/cpuinfo 也确实能看到 v 扩展——但一跑向量程序，直接崩溃：

Illegal instruction (core dumped)   # 退出码 132 = SIGILL

排查过程：

# ① 确认 CPU 模拟出 v 扩展（确实有）
grep -o '^isa[^,]*' /proc/cpuinfo        # rv64imafdc_zba_zbb_zbs_v ...

# ② 查内核是否允许用户态使用向量 —— 问题在这！
zcat /proc/config.gz | grep RISCV_ISA_V  # CONFIG_RISCV_ISA_V is not set

根因：QEMU 模拟出 v 扩展 ≠ 内核允许用户态使用它。openEuler 25.03 发行版内核显式关闭了 CONFIG_RISCV_ISA_V（尽管上游 Linux 6.6 默认是 y）。内核不开这项 = 不保存/恢复向量寄存器上下文，用户态任何 v 指令直接非法。换什么 -cpu 都没用，因为问题出在内核，不是 QEMU。

顺带说一句：Debian/Ubuntu 的 riscv64 内核默认开 RVV，同样的二进制在两边行为不同——这种"发行版级差异"正是验证工作的价值点，也是我给社区提交验证报告时发现的。

3.3 坑 7：qemu-user 的 -cpu rv64,v=true 不生效

想用 qemu-user 绕开内核限制，结果发现 -cpu rv64,v=true 在 user 模式下根本不解析出 v 扩展（该 CPU 名解析不带 v）。正确姿势是用默认 CPU 或 -cpu max：

# ✅ 正确：qemu-user 不经目标内核，RVV 由 QEMU 翻译层执行
qemu-riscv64 -L /usr/riscv64-linux-gnu -cpu max ./vec
# 预期输出：VLEN bytes: 32   （256 位向量 = 32 字节）

# 调向量长度：默认 128 位 → 指定 256 位
qemu-riscv64 -L /usr/riscv64-linux-gnu -cpu max,vlen=256 ./vec

这就是绕过内核 RVV 限制的官方推荐路线：qemu-riscv64 -L <sysroot> <binary> 直接在 x86 宿主机翻译执行 riscv64 指令，根本不经过目标内核，RVV 由 QEMU 翻译层执行。我实测用它跑通了 RVV 向量加法（bad=0 PASS）、甚至完整的 MLAS RVV SGEMM kernel 11/11 单元测试（vlen=128 和 vlen=256 都过，maxdiff ≤ 0.000156）。结论：发行版缺 RVV 支持时，正确性验证完全不需要 VM/真机。

3.4 坑 8：RVV 循环必须用分段循环（stripmining）

写向量代码时我还踩了一个隐蔽坑：循环如果不按 vlenmax 分段、而是假设一次装完所有元素，超过 vlenmax 时数值会静默错乱（qemu-user 下实测，不报错只给错答案）。RVV 的标准写法是分段循环：

size_t vlmax = __riscv_vsetvlmax_e32m1();   // 一次最多处理几个 f32
for (size_t vl; n > 0; n -= vl, a += vl, b += vl, c += vl) {
    vl = __riscv_vsetvl_e32m1(n);           // 本次处理 min(n, vlenmax) 个
    vfloat32m1_t va = __riscv_vle32_v1(a, vl);
    vfloat32m1_t vb = __riscv_vle32_v1(b, vl);
    vfloat32m1_t vc = __riscv_vfadd_vv_f32m1(va, vb, vl);
    __riscv_vse32_v1(c, vc, vl);
}

每个循环迭代用 vsetvl 重新截断本次要处理的元素数，这是 RVV 与固定宽度 SIMD 最本质的思维差异。如果总元素数超过 vlenmax 而你只循环了一次，QEMU 不会报错——它只是默默地把超出部分留在寄存器里没写回内存，你拿到的是错乱的结果。这种"静默出错"比崩溃更可怕，排查起来极费时间。

四、自编译内核：从根上解决向量支持

qemu-user 能验证正确性，但真要在 openEuler VM 里跑向量程序，还得自编一个开了 CONFIG_RISCV_ISA_V 的内核。这也是最完整的进阶闭环。

4.1 获取 OLK 源码

OLK = Open Euler Kernel，openEuler 官方内核仓，全架构同一仓库多分支：

# 浅克隆 OLK-6.6（约 200+MB，--depth 1 省流量）
git clone --depth 1 -b OLK-6.6 https://gitee.com/openeuler/kernel.git ~/riscv/oe/olk-6.6

# 确认版本（Makefile 前 5 行）
head -5 ~/riscv/oe/olk-6.6/Makefile
# VERSION = 6 / PATCHLEVEL = 6 / SUBLEVEL = 0 / EXTRAVERSION = -72.6.0.56.oe2503

4.2 config 配置：三条路 + 一个大坑

export ARCH=riscv
export CROSS_COMPILE=riscv64-linux-gnu-
cd ~/riscv/oe/olk-6.6

# 路线 A（推荐）：用 VM 现役内核的 config，保证与官方行为一致
# VM 里执行：zcat /proc/config.gz > /tmp/oe.config
# 然后 scp 回 WSL
cp ~/riscv/oe/current.config build/.config

# 路线 B：源码自带 defconfig（实测 7396 行）
make O=build openeuler_defconfig

⚠️ 坑 9：defconfig ≠ 发行版实际 config。这是我最惊讶的发现：OLK 主仓的 openeuler_defconfig 实测 CONFIG_RISCV_ISA_V=y（RVA23 方向已默认开），但 25.03 发行版内核 config 显式关了它——官方发布内核的 config 在 src-openeuler/kernel 的 spec 里，跟源码树 defconfig 不一致。要复刻官方行为就用路线 A（现役 config），要新能力就用 defconfig 再微调。

4.3 显式开启向量支持

# 在现役 config 基础上开向量 + IKCONFIG（/proc/config.gz 依赖它）
./scripts/config --file build/.config -e RISCV_ISA_V -e IKCONFIG
make O=build olddefconfig

# 关键：验证开关真的生效（别信 menuconfig 显示）
grep RISCV_ISA_V build/.config    # 必须看到 CONFIG_RISCV_ISA_V=y

4.4 交叉编译内核

make O=build -j6 Image dtbs modules
# 产物：
#   build/arch/riscv/boot/Image   —— 内核镜像（QEMU -kernel 用它）
#   vmlinux                       —— ELF（调试用）
#   build/.config                 —— 最终生效 config

file build/arch/riscv/boot/Image  # ELF 64-bit LSB executable, UCB RISC-V

⚠️ 坑 10：WSL 内存雪崩。第一次我用 -j$(nproc)（8 核）并行编译 + 4G VM，直接把 WSL 的 32GB 内存打满，WSL 服务整个挂死（0x8007274c），只能 wsl --shutdown 重启。铁律：限 -j6，这是本项目反复验证的教训。

⚠️ 坑 11：报 certs/openeuler-cert.pem 不存在。openEuler 内核 spec 会带签名证书路径，源码树里没有。解法：make menuconfig 里清空 Cryptographic API > Certificates for signature checking > Additional X.509 keys，或 config 关 CONFIG_MODULE_SIG。

4.5 替换 VM 内核（推荐先直启验证）

替换内核有两条路线，先直启、再装盘是最稳的顺序：

路线 1：QEMU -kernel 直启新内核（推荐做实验，不动 VM 磁盘）

qemu-system-riscv64 -machine virt -smp 8 -m 4G \
  -kernel ~/riscv/oe/olk-6.6/build/arch/riscv/boot/Image \
  -append 'root=/dev/vda1 rw console=ttyS0 swiotlb=1 selinux=0 highres=off earlycon' \
  -drive file=<你的qcow2>,format=qcow2,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -netdev user,id=n1,hostfwd=tcp::12056-:22 \
  -device virtio-net-device,netdev=n1 -nographic

⚠️ 坑 12：-kernel 只认 Image，不认 vmlinuz。磁盘里 /boot/vmlinuz-* 是压缩过的内核（uImage 格式，带自解压头），QEMU -kernel 期望的是未压缩的 raw 内核 Image（arch/riscv/boot/Image）。格式不对，启动直接崩或没反应。

路线 2：完整安装进 VM（装盘，可重启生效）

# 宿主：打包模块
make INSTALL_MOD_PATH=./modroot modules_install
tar czf ~/riscv/oe/kmods.tgz -C ./modroot lib
scp -P 12055 build/arch/riscv/boot/Image ~/riscv/oe/kmods.tgz linght153@127.0.0.1:~/

# VM 内：
sudo cp ~/Image /boot/vmlinuz-6.6.0-custom
sudo tar xzf ~/kmods.tgz -C /
sudo dracut --kver 6.6.0-custom -f /boot/initramfs-6.6.0-custom.img
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grubby --set-default /boot/vmlinuz-6.6.0-custom
# 重启前先 grubby --info=ALL 确认新条目存在（VM 重启由你自己手动执行）

4.6 验证闭环：向量真的可用了

uname -r                                   # 你的自定义版本号
zcat /proc/config.gz | grep RISCV_ISA_V    # CONFIG_RISCV_ISA_V=y

# 编一个向量程序跑——之前必然 SIGILL，现在正常输出
gcc -march=rv64gcv -O2 -o vec vec.c && ./vec
# 输出：VLEN bytes: 32（QEMU virt 默认 VLEN 256）

那一刻看到向量程序第一次在 openEuler VM 里正常输出，之前所有的坑都值了。

结尾总结

最大的认知升级：QEMU 模拟出扩展 ≠ 内核允许用户态使用。遇到 SIGILL 先查目标内核的 config，而不是怀疑编译器或 QEMU；而 qemu-user 这把"绕过内核"的钥匙，让 RISC-V 软件的正确性验证可以完全脱离真机和 VM 进行。这套"交叉编译 + qemu-user 验证 + VM 只跑产物"的工作流，现在已经成为我日常做 RISC-V 软件移植的标准姿势。

给后来者的建议：按"先交叉编译 → 再 qemu-user 跑通 → 需要真机性能/内核特性时再上 VM 或真机"的顺序推进，每一步的验证手段都简单直接；遇到 Illegal instruction 先查 /proc/cpuinfo 和内核 config，别一头扎进编译参数里。RISC-V 生态还年轻，坑多但成长快，把这些实测记录沉淀下来，就是给社区最好的贡献。

作者：一名在 x86 电脑上"白嫖"到一台 RISC-V 电脑的学习者

关键词：openEuler、RISC-V、QEMU、虚拟机、gcc、hello world

一、写在前面：为什么我非要折腾一台"假"的 RISC-V 电脑

最近在跟着 openEuler RISC-V 相关的学习资料做入门实践，第一道坎就是：我手上没有 RISC-V 开发板，怎么办？

答案就是 QEMU——一个开源模拟器，可以在我的 x86 电脑上"假装"出一台完整的 RISC-V 电脑（CPU、内存、硬盘、网卡全都有），然后在里面装一个真正的 openEuler RISC-V 操作系统。更妙的是，QEMU 用的是纯软件模拟（TCG 技术），不需要 CPU 支持硬件虚拟化，也不用去 BIOS 里开 VT-x，装完就能用。

这篇文章就是我的完整实操记录：从装 QEMU、下载镜像、启动虚拟机，到在 riscv64 系统里编译运行我写的第一个 C 程序。全程第一人称踩坑实录，零基础可跟。

我的环境：Windows 11 + WSL2（Ubuntu 22.04），所有命令都在 WSL 终端里执行。如果你用 Windows 原生 PowerShell 或 macOS，命令大同小异，我在文末踩坑区会标注差异点。

二、环境准备：装 QEMU 并完成"验证三连"

2.1 安装 WSL（Windows 用户）

管理员身份打开 PowerShell，执行：

wsl --install

重启后按提示设置 Ubuntu 的用户名和密码（记好这个密码，sudo 要用）。装好后打开"开始菜单 → Ubuntu"进入 Linux 终端。

2.2 安装 QEMU

在 WSL 终端里依次执行：

sudo apt update
sudo apt install -y qemu-system-misc qemu-utils

qemu-system-misc 这个包里就包含了 riscv64 等"杂项架构"的全系统模拟器，qemu-utils 提供 qemu-img 工具。装完 qemu-system-riscv64 就在系统里了。

2.3 验证三连（装完必做）

qemu-system-riscv64 --version
qemu-system-riscv64 -machine help | grep virt
qemu-img --version

我的实际输出：

QEMU emulator version 8.2.2 (Debian 1:8.2.2+dfsg-1~22.04.5)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

virt              RISC-V VirtIO Board (default)

三条全过 = QEMU 装好了。要求版本号 ≥ 7.0，因为 openEuler 24.03 LTS 的官方镜像和启动脚本是按新版 QEMU 写的；-machine help 里能看到 virt 行说明模拟器支持 openEuler 官方镜像默认的机器型号。

💡 踩坑预警：如果你的 WSL 里 apt update 卡住不动，多半是 Ubuntu 官方源在大陆网络慢，把 /etc/apt/sources.list 里的 archive.ubuntu.com 换成清华或阿里镜像源再试。

三、下载镜像：三个文件，一个都不能少

打开 openEuler 官方下载页：https://www.openeuler.org/zh/download/，找到 24.03 LTS 版本 → RISC-V 架构分区 → 虚拟机镜像区，下载这四个文件到 ~/riscv-lab/ 目录：

openEuler-24.03-LTS-SP3-riscv64.qcow2.xz   # 磁盘镜像压缩包，约 3-5GB，最大最慢
RISCV_VIRT_CODE.fd                          # UEFI 固件-代码（几 MB）
RISCV_VIRT_VARS.fd                          # UEFI 固件-变量（几 MB）
start_vm.sh                                 # 官方启动脚本（几 KB）

三个文件的角色：.qcow2.xz 是整块硬盘（装了 openEuler 系统，被 xz 压缩打包了）；两个 .fd 是UEFI 固件（电脑开机第一段代码，负责把系统从硬盘里叫醒）；start_vm.sh 是官方写好的启动说明书。

下载完做两件事：

1. 看大小：qcow2.xz 应该有 3-5GB，如果只有几百 MB，多半是下载中断了，删掉重下。
2. 校验完整性：用 sha256sum 对比下载页给的校验值，整串一致才放心：

cd ~/riscv-lab
sha256sum openEuler-24.03-LTS-SP3-riscv64.qcow2.xz

⏳ 踩坑预警：镜像下载慢是大陆网络的老大难。我的解法三件套：① 用支持断点续传的下载工具（IDM/迅雷），断了不用从头来；② 换清华镜像源 https://mirrors.tuna.tsinghua.edu.cn/openeuler/，路径结构和官方站一致；③ 实在不行就半夜下（说多了都是泪，但真的快）。

四、解压 + 启动：那条 200 字符的长命令，逐参数看懂

4.1 解压镜像

cd ~/riscv-lab
xz -dk openEuler-24.03-LTS-SP3-riscv64.qcow2.xz

-d 是解压（decompress），-k 是保留原压缩包。解压要等 1-5 分钟，终端没输出是正常的。完成后 ls -lh 应该能看到不带 .xz 后缀的 qcow2 文件（解压后约 5-7GB）。

4.2 启动命令逐参数拆解

第一次启动，我建议直接用官方 start_vm.sh，但一定要看懂它在干什么。它的核心就是下面这条命令（我整理成了经典写法，每个参数独立一行，行尾 \ 只是续行符）：

qemu-system-riscv64 \
  -machine virt -m 4G -smp 4 \
  -drive file=openEuler-24.03-LTS-SP3-riscv64.qcow2,format=qcow2,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -netdev user,id=n0,hostfwd=tcp::12055-:22 \
  -device virtio-net-device,netdev=n0 \
  -nographic

用人话翻译：“QEMU，请模拟一台 RISC-V 电脑（virt 型号），给它 4GB 内存、4 个 CPU 核心；把 qcow2 文件当作硬盘接上；给它一张能上网的虚拟网卡，并把宿主机的 12055 端口转发到虚拟机的 22 号端口；不开图形窗口，所有输出走终端。”

各参数逐个说：

📌 这里最重要、全书必考的是 hostfwd=tcp::12055-:22：它决定了你后面能不能 SSH 进虚拟机。22 是 SSH 默认端口，12055 是宿主机上的映射端口（高位端口，避免和宿主机自己的 22 冲突）。想换就换，但换了以后 SSH 命令的 -p 参数要跟着改。

4.3 启动！你会看到四个阶段

./start_vm.sh

💡 踩坑预警：如果报 Permission denied，说明脚本没有执行权限，先 chmod +x start_vm.sh 再运行。如果报 command not found，检查 pwd 确认你在 riscv-lab 目录里。

回车后耐心等待 1-3 分钟，启动日志按这个顺序刷屏：

OpenSBI v1.4
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
...（固件先醒来，确认自己在 QEMU 的 virt 机器上）

[    0.000000] Linux version 6.6.0-76.0.0.76.oe2403.riscv64 (oe-build@localhost) ...
[    0.000000] CPU: rv64imafdc_zicsr_zifencei_zba_zbb_zbc_zbs ...
[    0.000000] 4 CPUs detected
[    1.234567] virtio_blk virtio0: [vda] 62914560 512-byte logical blocks (32.2 GB)
[    3.456789] systemd[1]: Running in virtual machine.
[  OK  ] Started OpenSSH server daemon.
[  OK  ] Reached target Multi-User System.

openEuler Linux 24.03 (LTS)

Kernel 6.6.0-76.0.0.76.oe2403.riscv64 on an riscv64

localhost login:

看到 login: 提示符，你的第一台 RISC-V 虚拟机就启动成功了！ 重点看三处：Linux version ...riscv64（RISC-V 世界的内核）、virtio_blk ... [vda]（你的 qcow2 硬盘被识别了）、on an riscv64（架构实锤）。

4.4 登录 + 立刻改密码

localhost login: root
Password: openEuler12#$

openEuler RISC-V 官方镜像默认密码是 openEuler12#$（#$ 是密码的一部分，一共 13 个字符，别把 # 打成中文的）。输密码时屏幕什么都不显示——这是 Linux 的安全设计，不是键盘坏了，盲打回车即可。

登录成功提示符会变成 [root@localhost ~]#（# 是 root 用户的标志）。第一件事改密码：

passwd

⚠️ 默认密码全世界都知道，登录后必须立刻改。密码至少 8 位，建议字母+数字+符号混合。忘了密码很麻烦（要进单用户模式重置），一定记牢。

五、换个姿势进门：SSH 远程登录

在 QEMU 黑窗口里操作只是第一步，真实服务器工作流全靠 SSH。回到宿主机终端：

ssh root@127.0.0.1 -p 12055

第一次连接会弹"主机指纹确认"提示（这是 SSH 的防伪机制，防止有人冒充你的 VM），输入完整的 yes 回车，然后输 VM 的 root 密码。登录后验证一下：

uname -m

输出 riscv64——你在 x86 宿主机上，手却伸进了 riscv64 的虚拟机，这就是 12055 端口转发的功劳。

💡 进阶一步：ssh-keygen -t ed25519 生成密钥对，再 ssh-copy-id root@127.0.0.1 -p 12055 把公钥登记进 VM，以后 ssh root@127.0.0.1 -p 12055 免密直进，传文件用 scp -P 12055 文件 root@127.0.0.1:/root/（注意 scp 是大写 -P，ssh 是小写 -p，这个坑坑过无数人）。

六、第一个 RISC-V 程序：从装 gcc 到跑通 hello

6.1 装编译器

在 VM 里执行（注意提示符是 [root@localhost ~]#，别在宿主机敲）：

dnf install -y gcc

注意输出里这行：gcc riscv64 12.3.1-2.oe2403——你装的是 riscv64 版的 gcc，它编译出来的机器码就是 RISC-V 方言，这就是"原生编译"。验证：

gcc --version

gcc (GCC) 12.3.1 20230508 (openEuler 12.3.1-2.oe2403)

6.2 写 hello.c

nano hello.c

输入（强烈建议手敲一遍，别复制）：

#include <stdio.h>

int main(void)
{
    printf("Hello from RISC-V!\n");
    return 0;
}

Ctrl+O 保存，Ctrl+X 退出。逐行含义一句话版：#include <stdio.h> 是引入标准输入输出库的"说明书"；int main(void) 是程序唯一的大门，CPU 从这里开始执行；printf 把文字打到屏幕，\n 是换行，行尾分号 ; 是 C 语言的"句号"（漏掉它是新手第一大报错来源）；return 0 表示程序正常结束。

6.3 编译 → 运行 → 验证架构（三连）

gcc hello.c -o hello
./hello
file hello

我的实际输出：

Hello from RISC-V!

hello: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, not stripped

三个要点：

1. gcc hello.c -o hello 编译成功是"沉默"的——没有任何输出就是最好的输出（注意 -o 是小写字母 o，不是数字 0）。
2. 运行必须写 ./hello——Linux 默认不在当前目录找命令，直接敲 hello 会报 command not found。
3. file hello 是本章最有成就感的时刻：输出里 UCB RISC-V 就是架构实锤（UCB = 加州大学伯克利分校，RISC-V 的诞生地，名字留在了 ELF 格式里）；RVC 表示用了压缩指令扩展；/lib/ld-linux-riscv64-lp64d.so.1 是 riscv64 的程序加载器。

强烈建议做个对照实验：把 hello.c 在 x86 宿主机上也编译一次，file 输出会变成 ELF 64-bit ... x86-64 ...——同一个源码，不同架构的编译器，产出不同"方言"的机器码。把 VM 里编的 hello 拷到宿主机运行，会报 Exec format error（架构不对，不是文件坏了）。架构的壁垒，这一刻你亲手摸到了。

七、踩坑合集：我替你踩过的坑

八、总结：我这一路学到了什么

从零到跑通第一个 RISC-V 程序，我完成了三件有里程碑意义的事：

1. 装好了 QEMU，用纯软件模拟在 x86 电脑上"无中生有"了一台 RISC-V 电脑——不需要真机，不需要硬件虚拟化。
2. 看懂了一条 200 字符的 QEMU 启动命令：-machine 选机型、-m 给内存、-smp 给核数、-drive 挂硬盘、-netdev hostfwd 做端口转发、-nographic 走终端。从此虚拟机在我眼里不再是"黑魔法"，而是一台参数明确的电脑。
3. 在 riscv64 上原生编译并运行了自己的程序，并且用 file hello 亲眼看到了 UCB RISC-V 的字样——那一刻我才真正理解了什么是"架构"：同一个 printf，x86 和 RISC-V 会翻译成完全不同的机器码，程序必须在目标架构上编译才能运行。

下一步我准备挑战交叉编译：在 x86 宿主机上用 riscv64-linux-gnu-gcc 编出 riscv64 的程序，再用 qemu-riscv64（用户态模拟）直接验证——“编译放宿主机、运行验证靠模拟器”，这是 RISC-V 软件生态里最常用的生产工作流，也是我实习测评工作的标准姿势。等我把 RVV 向量扩展也玩明白了，再来分享第二篇。

如果这篇文章帮到了你，或者你在实操中遇到了其他坑，欢迎评论区交流。RISC-V 的世界，入门真的没有想象中那么难。