企业官网建设流程全解析

前阵子把手头一块 Banana Pi BPI-SM10 开发板翻出来，板载芯片的指令集扩展符合 RVA23 profile，H 扩展和 Sstc 都齐全。装完官方 Linux 之后，我决定干一件有点“不务正业”的事：把 Bao hypervisor 从熟悉的 ARM64 世界搬到这块 RISC-V 板子上。Bao 是一个静态分区 Type-1 hypervisor，代码量小，隔离性硬核。这篇文章就是这次移植的完整记录，重点放在 RISC-V 特有、也是最劝退的 link.ld 链接脚本、RISC-V 指令集的虚拟化扩展，以及 BPI-SM10 上从无输出到多 guest 同时跑的排坑过程。考虑到板子批次和文档版本可能不一样，凡是涉及具体地址或寄存器值的地方，我都会说明“以你的 BSP 实际值为准”，而不是死记一个数字。

1. 项目背景与整体移植思路

1.1 为什么选 Bao 而不是 KVM / Xen

说到 RISC-V 上的 hypervisor，很多人第一反应是 KVM 或者 Xen。KVM 在 Linux 里已经比较成熟，Xen 的社区也在推进 RISC-V 支持，但这两个都是重量级方案：动态调度、动态内存管理、设备模型，代码量几十万行级别。对于我这种想在一块嵌入式开发板上快速搞出“多个隔离系统同时跑”的人来说，太重了。

Bao 的路子完全不同。它是静态分区 hypervisor，开机后 CPU 核心、内存区间、外设中断全部在编译时定死，运行时不做动态创建、不做抢占调度。这种模式特别适合两类场景：一类是汽车和航空里的硬实时系统，要的是确定性，不允许调度抖动；另一类是安全隔离，几个 guest 之间内存彻底隔开，没有共享页表，攻击面小。Bao 的代码量很小，核心代码几万行就能说清楚，移植到新平台时可控性强。这几点加起来，让我决定把 Bao 作为这次移植的主角。

对比下来：

1.2 RVA23 profile 给 hypervisor 铺了哪条路

RVA23 是 RISC-V International 发布的应用级 profile，里面把一系列扩展固定成了“必须实现”。对我们做 hypervisor 的人来说，最关键的是一条：H 扩展（hypervisor extension）是 RVA23 的必选项。这意味着 BPI-SM10 这类板子在设计时就带上了完整的硬件虚拟化能力，包括 hgatp 两阶段地址翻译、guest 外部中断注入、异常委托这些机制。

在 RVA23 之前，很多 RISC-V 芯片虽然变成了“支持虚拟化”，但实际就靠 trap-and-emulate，guest 一碰敏感寄存器就陷入 hypervisor 软件模拟。RVA23 把 H 扩展列为必须，同时把 Sstc（supervisor timer 比较寄存器）、Svinval（高效 TLB 刷新的指令）、Zicbom / Zicboz（缓存管理操作）这些和虚拟化关系密切的扩展也一并纳入。对移植者来说，最大的好处是不用再纠结“这颗芯片到底有没有虚拟化硬件”，只要确认它标注了 RVA23，Bao 就能用上原生的虚拟化能力。

1.3 移植路径：从编译通过到多 guest 启动

这次移植我给自己定了四个阶段，每个阶段有明确的验收标准：

1. 搭好交叉编译环境，让 Bao 源码在PLATFORM=bpism10下编译出 elf 和 bin。
2. 适配 link.ld 链接脚本，让_start能在 BPI-SM10 的 DDR 地址上稳定执行，串口能看到 hello 输出。
3. 完成 platform 描述和设备树规划，让 Bao 能识别核心、内存、UART、中断控制器。
4. 加载两个 guest：一个裸机串口打印程序和一个裁剪过的 Linux，验证静态分区隔离。

实际操作中，第 2 步花的时间比第 3、4 步加起来还多。RISC-V 的“文化”和 ARM64 不太一样，ARM 那边一般有人给你整包的 BSP，link.ld 都是现成的；RISC-V 这边经常要自己从零搭链接脚本，这就是为什么 “risc-v link.ld” 会成为一个热词。

2. 环境准备：交叉工具链与运行固件

2.1 工具链选型与编译参数

RISC-V 的交叉工具链有好几种选择，我这次用的是riscv64-linux-gnu-gcc。虽然是 Linux 工具链，但 Bao 本身不依赖 libc，是纯裸机代码，所以带 glibc 的工具链也完全没问题。如果你手头有riscv64-unknown-elf-gcc当然更好，区别不大。

安装方式：

sudo apt install gcc-riscv64-linux-gnu # 或者从 bootlin 官方下载预编译工具链，解压后加到 PATH

做 hypervisor 裸机编译，有两个编译参数建议显式加进 Baom 的 CFLAGS 里，一个是-mcmodel=medany，一个是-fno-pic。medany是 RISC-V 特有的寻址模型，它会让编译器生成相对当前 PC 的地址访问，不依赖绝对地址到高 4GB 之外。-fno-pic避免生成位置无关代码，因为 Bao 链接地址就是运行地址，不需要重定位。

-march参数上不要贪多。我见过有人直接写-march=rv64imafdcv，带上向量扩展 V，结果链路上下文里多了一堆向量寄存器保存恢复代码，还容易触发工具链版本差异。RVA23 平台通常有 V 扩展，但 Bao 用不到，我建议用：

CFLAGS += -march=rv64imafdc_zba_zbb_zbs_zicbom_zicboz_zihintpause_sstc

后面几个小扩展是 RVA23 里常见的基础扩展，不影响大局，但能让工具链生成更干净的代码。

2.2 启动链：OpenSBI、U-Boot 与特权级

RISC-V 有明确的特权级设计：M 模式（machine）、HS 模式（hypervisor-supervisor）、VS 模式（virtual-supervisor）。BPI-SM10 的启动链通常是：

片上 ROM -> OpenSBI（M 模式） -> U-Boot（HS 模式） -> 用户程序

这里有个关键概念：当 CPU 实现了 H 扩展，原本的 S 模式就升级成 HS 模式，S 模式下的 Linux 能跑是因为它用 SBI 接口和 M 模式的 OpenSBI 通信。U-Boot 如果编译成 S-mode 版本，它实际跑在 HS 模式。

Bao 作为 hypervisor，要求的正是 HS 模式。所以最简单的加载方式就是让 U-Boot 用go命令直接跳转到 Bao 入口，不需要再经过 OpenSBI 切一趟。个中原因是 H 扩展的 CSR（比如 hstatus、hgatp）只能在高于等于 HS 模式时访问，U-Boot 已经在 HS，Bao 继承这个状态即可。

2.3 获取 Bao 源码与目录结构

Bao 的源码托管在 GitHub：

git clone https://github.com/bao-project/bao-hypervisor.git cd bao-hypervisor git checkout <你验证过的稳定分支>

源码结构大致如下：

• src/：核心代码，内存管理、vCPU 切换、中断处理。
• arch/riscv64/：RISC-V 体系结构相关代码，CSR 操作、异常入口。
• platforms/：板卡相关代码，每种板一个目录。
• config/：VM 配置，通常用 DTS 描述。

Bao 的 VM 配置在较新版本里已经演进成用 DTS 描述，编译时生成 DTB 嵌入镜像。这样好处很明显：硬件资源划分写在文本格式里，可读性好，不用每次改 guest 分区都重新动 C 源码。

3. 移植第一关：RISC-V 的 link.ld 链接脚本

3.1 为什么 RISC-V 的 link.ld 这么让人头疼

如果你在网上搜过 “riscv link.ld”，会发现提问特别多，因为 RISC-V 的链接脚本有几个和指令集绑定的特殊约束，和 x86/ARM 完全不是一个套路。

第一个坑是全局指针寄存器 gp。RISC-V 编译器默认会把小数据放进.sdata、.sbss段，然后用 gp 寄存器做相对寻址。如果链接脚本里没有定义这两个段，或者它们在内存里的位置不合适，编译时就会报一堆R_RISCV_GPREL_Irelocation truncated。很多新手第一次写 RISC-V 链接脚本就栽在这。

第二个坑是启动阶段的寻址模型。hypervisor 在打开分页之前，运行在物理地址上，所有代码必须链接到真实物理地址。ARM64 早期也有类似要求，但 ARM 的启动代码通常有__boot_args之类的封装；RISC-V 这边你得自己在_start里处理 a0（hartid）、a1（DTB 地址），以及 sp、gp、tp 的初始化。

第三个坑是对齐。RISC-V 的指令编码里，跳转指令auipc+jalr是 4 字节对齐，但这不代表你的段可以随意 4 字节对齐放。有些原子操作和缓存行优化需要 16 字节甚至更大对齐，链接脚本里不加. = ALIGN(16);，后面调试时会出现诡异问题。

所以说，link.ld 不是可有可无的“构建配置”，它是 RISC-V 移植的第一道关卡。

3.2 内存布局：Bao、Guest、DTB 怎么放

在动手写链接脚本前，必须先规划整个内存布局。BPI-SM10 的 DDR 起始地址一般是0x80000000，低地址区间被 OpenSBI 和 U-Boot 占用。我给这块板规划的布局如下：

为什么挑0x80200000作为 Bao 的加载地址？两个原因。第一，这是 RISC-V Linux 内核惯用的加载地址，U-Boot 和 OpenSBI 对它很熟悉，不容易踩到固件尾巴。第二，它离 DDR 起点有 2MB 距离，给固件、DTB、页表预留了充足空间。如果你用 QEMU 验证，virt机器的内存也是从0x80000000开始，这套布局完全兼容。

3.3 一份可用的 RISC-V link.ld 骨架

直接给一份我实际调试过的链接脚本骨架，按 Bao 的风格精简：

OUTPUT_ARCH(riscv) ENTRY(_start) BASE_ADDRESS = 0x80200000; SECTIONS { . = BASE_ADDRESS; _start = .; .text : { *(.text._start) *(.text*) } . = ALIGN(16); _etext = .; .rodata : { *(.rodata*) *(.srodata*) } . = ALIGN(16); _erodata = .; .data : { *(.data*) *(.sdata*) } . = ALIGN(16); _edata = .; .bss (NOLOAD) : { __bss_start = .; *(.bss*) *(.sbss*) *(COMMON) . = ALIGN(16); __bss_end = .; } . = ALIGN(16); _end = .; }

几个关键点：

• ENTRY(_start)告诉链接器入口符号是_start，它必须放在镜像最开头。为了保险，我把启动汇编单独放进.text._start段，避免其他代码段挤到前面。
• .srodata、.sdata、.sbss这些 gp 相关小段必须显式列出，否则编译器生成的 gp 相对寻址找不到段，轻则链接失败，重则运行时访问错误数据。
• bss用了NOLOAD，只在 ELF 里标记一段内存区域，不把几百 KB 的零填充塞进 bin 文件。没有这一行，生成的 bin 会膨胀到不可思议。
• 所有段之间都加ALIGN(16)，这是给后续页表映射和缓存维护做铺垫。

链接脚本最后导出的_end、__bss_start这些符号，C 代码里的memset清 BSS、内存分配器都会用到。少了它们，等着链接错误找到你。

3.4 我踩过的四个 link.ld 实战坑

先说第一个坑：rodata对齐不足。最开始我的.rodata用了ALIGN(8)，编译出来的内核一启动就指令异常。后来用调试器看，是一条ld指令的立即数寻址越界，改成 16 字节对齐就没了。

第二个坑：gp 段缺失。有一版链接脚本我图省事没写.sdata，结果链接器直接报一堆 relocation truncated。开始我还以为是内存地址太高了，后来才发现是 gp 寻址表没建起来。

第三个坑：_start里的a0和a1被编译器破坏了。RISC-V 启动规范要求 OpenSBI 传入的 a0 是 hartid，a1 是 DTB 物理地址，但有些汇编代码里第一句就执行了其他操作，把 a1 覆盖了。正确做法是入口处先保存a0、a1到内存，再干别的。

第四个坑：链接地址和加载地址不一致。这多半发生在你从 U-Boot 加载时用了0x80200000，但 link.ld 里BASE_ADDRESS写成了0x80000000。启动后第一条指令能跑，但一跳转到 C 函数就飞了，串口毫无输出。排查方式是在_start开头直接串口打印 PC 值，和链接地址对照一下即可。

4. 平台描述、设备树与资源规划

4.1 在 Bao 里新增平台描述

Bao 的架构把平台相关逻辑抽象成一套描述结构。你在platforms/riscv64/下新建一个bpism10目录，里面放平台描述 C 文件、链接脚本、Makefile 片段。平台描述文件的核心是给出这些信息：

struct bao_platform_desc { const char *name; uint64_t hart_num; uint64_t hart_freq; uint64_t region_base; uint64_t region_size; uint64_t uart_base; uint32_t uart_irq; uint32_t intc_type; /* APLIC / PLIC / IMSIC */ };

不同版本的字段名会有出入，但思路是一样的：告诉 Bao 有多少个 hart、内存从哪里开始多大、串口和外设在哪里。这些值必须从 BPI-SM10 的原理图和数据手册里逐个抠出来，不能凭空猜。如果你找不到数据手册，直接看官方 BSP 的 dts 文件，里面的memory、uart、plic节点会告诉你准确地址。

4.2 从数据手册或 DTS 里读哪些参数

移植 hypervisor 时要关注的参数比移植普通裸机程序多，因为要分配中断和内存给多个 guest。我列了一张自查表：

BPI-SM10 这类板子的 BSP 一般会在内核 dts 里把 SoC 地址写得很清楚。你需要的不是照着抄，而是把范围缩小到 hypervisor 和 guest 真正用到的部分，避免 guest 拿到过大的内存描述。

4.3 设备树是 guest 的“世界观”，必须裁剪

这里说一个很多教程没提的细节：Bao 是静态分区 hypervisor，但 guest 里跑 Linux 时，Linux 会去解析自己收到的设备树。如果你把 U-Boot 传过来的完整 DTB 直接给 guest，Linux 会认为自己拥有整个 DDR 的权限，然后疯狂初始化它看到的所有外设，包括其他 guest 占用的内存。这次第的结果不是启动失败，而是两个系统互相踩内存，连串口打印都是乱的。

所以正确做法是给每个 guest 一份“裁剪过的世界观”。用设备树工具链操作：

# 反编译 U-Boot 的完整 DTB dtc -I dtb -O dts -o full.dts u-boot.dtb # 手工编辑 full.dts，只保留当前 guest 需要的内容 # 修改 memory 节点为 guest 分区对应的地址范围 # 删除其他 guest 独占的设备节点 # 重新编译成 DTB dtc -I dts -O dtb -o guest0.dtb guest0.dts

裁剪的核心原则是“按需分配”：guest 的 DTB 里只描述它自己用到的 UART、定时器、PLIC/APLIC 节点，内存范围严格控制在 Bao 给它划分的区间内。第一次做 Linux guest 时，我建议先把 DTB 里的节点删到最简，跑通了再逐步加设备，排查起来容易得多。

5. RISC-V 虚拟化扩展：中断与定时器的底层细节

5.1 hgatp 和两个地址世界

RISC-V H 扩展最核心的机制是两阶段地址翻译。guest 自己用satp做虚拟地址到“guest 物理地址”的翻译；hypervisor 用hgatp做“guest 物理地址”到“机器物理地址”的翻译。硬件会自动把两级页表串起来，guest 完全感受不到第二级的存在。

打个比方：guest 以为自己的内存地图是一套真实户型图，但实际上那只是中介给你看的美化版；hypervisor 手里的hgatp才是楼盘真实图纸，标注了每一块地实际归谁。Bao 的静态内存隔离就是通过给每个 VM 建立独立的 G-stage 页表实现的，一个 VM 的 guest 物理地址 0x80000000 可能对应机器物理地址 0x81000000，另一个 VM 的 0x80000000 对应 0x82000000。

换个 vCPU 时要注意刷新 TLB。普通程序切satp用sfence.vma，但 hypervisor 切hgatp后，需要执行hfence.gvma或hfence.vvma这些 H 扩展特有的 fence 指令。RVA23 的 Svinval 扩展提高了这个操作的效率，但前提是你的代码真的调用了正确的 fence。

5.2 guest 外部中断：hgeip / hgeie 怎么用

中断注入是 hypervisor 最容易出 bug 的地方。RISC-V 在这里提供了一对专门用于虚拟化的 CSR：hgeip（hypervisor guest external interrupt pending）和hgeie（enable）。

当物理中断控制器（APLIC / PLIC / IMSIC）把某个中断定向到一个 vCPU 时，硬件会设置hgeip的对应位。如果你的平台把某个外设完全直通给了 guest，Bao 会开启hgeie，让这个中断直接以虚拟外部中断的形式呈现给 guest，hypervisor 不用每次中断都介入，延迟很低。如果某个中断需要 hypervisor 处理，Bao 就把该位关掉，物理中断 trap 到 HS 模式，软件处理后再重新分发。

实际配置时最容易犯的错是没把 PLIC/APLIC 的中断目标配成 guest vCPU 所在的 hart 和 context，导致中断来了之后hgeip永远不置位。排查时要同时检查中断控制器的 target 寄存器与hgeie，两边都对了中断才通。

5.3 虚拟定时器：Sstc 扩展带来的质变

RISC-V 的定时器体系这几年变化很大。早期实现里，S 模式要通过 SBI 调用请 M 模式的 OpenSBI 帮忙设置下一个定时器，一趟 ecall 来回开销不小。Sstc 扩展把stimecmp这个比较寄存器直接开放给 S/HS 模式，大家各自设置定时器，不再每次打断 M 模式。

但在虚拟化场景里，guest 自己写stimecmp会在 VS 模式触发 illegal instruction，陷入 HS 模式的 hypervisor。Bao 的做法通常是 trap-and-emulate：捕获 guest 对stimecmp的读写，换算成物理定时器的绝对时间，再设置真实的比较寄存器。由于 Bao 是静态分区，guest 对定时器的写操作频率很低，trap 开销完全可以接受。

RVA23 平台的 Sstc 是硬件必选，所以不用担心没有这个扩展。如果你是往更老的 RISC-V 板卡上移植，没有 Sstc 时就得走 SBI timer 兼容路径，代码要多一些分支。

6. 编译、加载与启动实测

6.1 编译步骤与常见编译错误

环境准备好之后，编译命令很简单：

export CROSS_COMPILE=riscv64-linux-gnu- make PLATFORM=bpism10

输出文件在bin/下面，bao.elf是带调试信息的 ELF，bao.bin是纯二进制镜像，加载时用 bin。

编译报错最常见的有两类。一类是relocation truncated to fit: R_RISCV_GPREL_I，处理方式去检查 link.ld 里.sdata和.srodata段是否声明、是否离 gp 定义位置太远。另一类是undefined reference to _end或__bss_start，说明链接脚本的符号导出和你 C 代码里的 extern 声明对不上。这些问题基本都能在 link.ld 里找到答案。

6.2 U-Boot 下加载 Bao 并跳转

把bao.bin放到 SD 卡 FAT 分区，进入 U-Boot 命令行：

setenv loadaddr 0x80200000 fatload mmc 0:1 ${loadaddr} bao.bin go ${loadaddr}

fatload从 mmc 0 的第一个分区读取文件到 0x80200000，go直接跳转执行。注意go和bootm不一样，bootm会解析镜像头，go是裸跳，所以必须加载 raw bin。

跳转后如果串口没有任何输出，优先怀疑三个地方：加载地址和链接地址不一致、UART 基址配置不对、_start汇编在设置串口前就崩了。我会在下一节给完整的排查思路。

6.3 启动日志逐段解读

正常启动时，Bao 会打印类似下面的日志：

Bao hypervisor v0.x - CPU: 8 hart(s) @ 1.0 GHz - RAM: 0x80000000 - 0x83FFFFFF - VM[0]: OK, entry=0x81000000 - VM[1]: OK, entry=0x82000000 - VM[2]: OK, entry=0x83000000

这段日志说明三件事：第一，Bao 已经从 HS 模式接管了所有 hart；第二，G-stage 页表建立完成，内存分区成功；第三，每个 VM 的 vCPU 上下文和中断配置都已就绪。如果日志卡在 “CPU: 8 hart(s)” 这一行之后不再往下走，通常是次要 hart 没有正确进入 C 代码，需要检查多核启动汇编里按 hartid 分配栈的逻辑。

6.4 多核启动的陷阱

RVA23 平台往往有多个 hart，甚至几十个。OpenSBI 跳转到 Bao 时，每个 hart 都会执行_start。如果_start代码里没有对 hartid 做区分，所有核会一起抢同一个栈、同一个初始化锁，直接崩掉。

我采用的模式是：入口先把 a0 hartid 存起来，根据 hartid 计算每个核的独立栈地址，主 hart（通常是 hart0）负责初始化内存管理、页表、中断控制器；其他 hart 自旋等待主 hart 发布启动信号。Bao 的架构里已经集成了类似机制，你要做的是在平台描述里正确提供栈空间大小和基址，别让不同核的栈重叠。

7. 问题排查与实测心得

7.1 问题排查速查表

整理一张表，方便后续参考：

7.2 先用 QEMU 再上板子，效率翻倍

移植 hypervisor 到新板卡，最痛苦的是每次调试都要烧 SD 卡、拔插、看串口。我的实践是先在 QEMU 的virt机器上把平台描述、链接脚本、中断路径全部验证一遍，再上板子。QEMU 支持 RISC-V 虚拟化扩展，命令如下：

qemu-system-riscv64 -machine virt -m 1G -nographic \ -bios opensbi.elf \ -device loader,file=bao.bin,addr=0x80200000

QEMU 里跑通之后，板子上大概率只是地址、时钟、串口这类设备差异，不会再有体系结构级别的 bug。这一步帮我省了至少三分之二的时间。

7.3 实测中断延迟与后续扩展

在 BPI-SM10 上，我让 guest0 跑一个裸机程序，定时翻转 GPIO，用逻辑分析仪量得中断响应大约 1.5 微秒左右。这个数字已经非常接近裸机水平，说明 Bao 在 RISC-V 上走的是一条低开销的直通路径，没有不必要的 trap。

接下来可以做的事还很多：给 guest 加 DMA 直通，需要配合平台 IOMMU 做地址映射；跑完整 Linux guest，需要把 rootfs 和 DTB 进一步裁剪；用 Bao 的多 VM 配置把 RTOS、Linux、裸机程序混合部署，形成典型的安全隔离方案。每一步都不容易，但基础一旦打好，后面都是体力活。

我个人在实际操作中的体会是：移植 hypervisor 到新的 RISC-V 板卡，真正卡人的不是 C 代码，而是 link.ld 和启动汇编这段“低频知识”。只要入口能稳定执行 C 代码、串口能打印日志，剩下的都是时间问题。最后再分享一个小技巧：我在_start里永远保留一个三行汇编写的串口打印函数，每次调整链接脚本或者内存布局后，先验证这个函数输出一个固定字符串再继续往下调。这个习惯已经救了我无数次。