在嵌入式圈子里干了这些年有一个变化是绕不开的以前一颗多核 SoC 上跑一个系统就够用现在越来越多的设备要求同一颗芯片上同时跑实时控制、人机界面、通信网关甚至一段裸机安全监控彼此还不能互相干扰。ZVM 就是冲着这个需求来的——一个面向嵌入式与边缘设备的轻量级分区虚拟化架构它把一颗多核 SoC 切成若干互相隔离的执行环境每个环境跑自己的操作系统或裸机程序靠设备树描述硬件归属靠一个极简的 vCPU 调度器把物理核分给各个虚拟机。这篇文章我不打算讲概念科普而是把 ZVM 这类架构里最难啃的两块拆开设备树怎么把一个物理硬件“分家”分干净以及多虚拟机跑起来之后 vCPU 怎么在物理核上排班。如果你正在做多系统合一的方案评估或者手上已经有一块开发板想验证分区虚拟化又或者你只是好奇一颗芯片怎么被切成三份还不打架下面的内容应该都能直接拿去参考。文中涉及的具体节点名、属性名是我按常见实践补的写法不同实现会有差异但设计逻辑是通用的。1. 架构选型为什么要在设备树之上做一层轻量 Hypervisor1.1 多系统合一是被成本逼出来的先说我遇到过的真实场景类型某工业网关项目需求是同一块板子上同时具备三件事——一个毫秒级响应的实时控制循环、一个带触屏的图形界面、一个负责协议转换和日志上报的通用系统。最直接的做法是双芯片实时那颗用 MCU界面和网关用一颗应用处理器中间走 SPI 或串口通信。选型会上算过账双芯片方案 BOM 多出十几块钱PCB 面积多占一圈还要多一路电源和时钟量产几十万台就是一笔不小的数字。另一个备选是 AMP也就是非对称多处理四颗核两颗跑实时系统两颗跑 Linux各自从固定地址启动中间靠共享内存通信。这个方案便宜但它有个致命弱点——隔离全靠自觉。裸机那边指针越界写进了 Linux 的内存区Linux 直接崩而且你很难查。更麻烦的是外设争抢两个系统都想初始化同一个串口控制器谁先谁后没有仲裁机制。分区虚拟化就是在这两者之间找到的平衡点硬件成本跟 AMP 一样隔离性接近双芯片。代价是要多一层软件以及随之而来的调试复杂度。ZVM 这类架构的核心价值就在这儿它不追求通用专攻“把硬件安全地切开”这件事。1.2 “轻量”到底轻在哪些地方很多朋友第一次接触这类架构会问它和跑在服务器上的那套通用虚拟化有什么区别区别大了主要集中在三点。第一是不做设备模拟。服务器虚拟化要模拟一块完整的网卡、一块 SCSI 控制器因为虚拟机里的操作系统期待见到标准设备。ZVM 这类方案不干这种事它走的是直通路线物理串口就是串口物理网卡就是网卡虚拟机直接访问寄存器Hypervisor 只在页表层面把这些 MMIO 区域划给它。省掉了模拟层代码量骤降访问延迟也接近原生。第二是没有完整的二级调度。通用虚拟化里虚拟机内的进程调度和 Hypervisor 的 vCPU 调度是两层独立机制配合起来很复杂。嵌入式场景下虚拟机数量通常是个位数静态分配加简单的时间片轮转就够用调度器可以压缩到千行以内。第三是启动路径极短。从引导程序交出控制权到第一个虚拟机开始跑整个流程在毫秒级。这在工业设备上很重要因为有些场景要求上电后极短时间内进入安全状态。我做过一次横向对比把三类方案的特性摊在表格里选型会上最好用维度双芯片方案AMP 裸跑ZVM 分区虚拟化硬件成本高低低内存隔离物理隔离无二级页表强隔离外设争抢不存在需人工约定设备树静态分配单点故障影响局部全局局部调试复杂度低中高启动时间秒级百毫秒级毫秒级1.3 整体分层与各组件的职责边界ZVM 的结构可以粗分成四层从上往下是管理接口、调度与虚拟化核心、配置解析、引导层。引导层负责把 Hypervisor 镜像和各虚拟机的镜像搬到内存里的正确位置然后跳转到 Hypervisor 入口。这一层通常由板载引导程序完成也可能是 Hypervisor 自带的一个小 loader。配置解析层就是设备树处理模块。它在 Hypervisor 初始化时读取物理设备树按分区规则裁剪出一份份“虚拟机视角”的设备树副本塞进各虚拟机的内存区。这一层的输出直接决定了后面虚拟机看到的世界长什么样。虚拟化核心包括三块CPU 虚拟化负责陷入陷出和系统寄存器上下文切换内存虚拟化维护二级页表中断虚拟化管理物理中断到虚拟中断的映射与注入。调度层是这个架构里唯一一个“纯软件策略”模块它决定某一时刻哪颗物理核跑哪个 vCPU。它的输入是设备树里给每个分区配的 CPU 亲和性和权重输出是一次次上下文切换。组件之间耦合最紧的是配置解析和虚拟化核心。设备树里写错一个地址表现出来可能是内存虚拟化阶段的映射失败也可能是虚拟机启动到一半跳飞到某个莫名其妙的地址。这也是为什么我在下面的章节里把设备树单独拎出来讲一大段。2. 设备树配置把硬件资源分家的第一现场2.1 设备树在虚拟化场景下的角色变化在普通的裸机或单系统 Linux 里设备树的作用是“告诉内核板子上有什么”。到了虚拟化场景它的角色变成了“告诉每个虚拟机它能用什么”这个转变带来的复杂度是数量级的。一份物理设备树进来至少要产出三份视图。第一份是 Hypervisor 自己的视图它需要知道全部硬件尤其是中断控制器、定时器、串口这些它要直接管理的设备。第二份和第三份是各虚拟机的视图每份都是物理设备树的一个子集加改写。改写规则很讲究。地址要改因为虚拟机看到的内存起始地址和物理地址不一样中断号要改因为物理中断号是全局唯一的而每个虚拟机内部都希望从中断号 32 开始数那些虚拟机不该看见的节点必须删掉比如指向别的分区内存的 reserved-memory 节点留着就是信息泄露还可能被误用。为什么用设备树而不是编译期硬编码因为板级差异太大。同一个 Hypervisor 二进制换一块板子只换 DTB 文件代码一行不动。这个好处在项目后期特别明显客户要换一款 SoC你只需要重写设备树不用重新走一遍回归测试。2.2 分区容器节点怎么写我给一个相对完整的写法示例这是我在项目里用过的结构属性名做了通用化处理/ { #address-cells 2; #size-cells 2; zvm: zvm-config { compatible zvm,partition-config; #address-cells 1; #size-cells 1; partition0 { zvm,id 0; zvm,name rtos; zvm,cpus 0 1; zvm,entry 0x0 0x80200000; reg 0x0 0x80000000 0x0 0x10000000; /* 256MB */ zvm,priority 10; zvm,time-slice-us 500; status okay; }; partition1 { zvm,id 1; zvm,name linux; zvm,cpus 2 3; zvm,entry 0x0 0x90200000; reg 0x0 0x90000000 0x0 0x20000000; /* 512MB */ zvm,priority 5; zvm,time-slice-us 1000; status okay; }; }; };这里几个属性需要解释。zvm,cpus是 vCPU 到物理核的亲和性映射写0 1表示这个分区的两个 vCPU 固定跑在物理核 0 和 1 上。zvm,entry是这个分区镜像的入口物理地址Hypervisor 启动该分区时就是跳到这个地址。reg描述分配给它的物理内存区间注意这个区间必须在物理内存范围内且不能和其他分区重叠这一点靠人工保证我后面会讲怎么校验。zvm,priority和zvm,time-slice-us是给调度器看的。这两个参数放在设备树里而不是编译进代码好处是现场调试时不用重编译改 DTB 重启就行。我在一个项目里就靠这个特性把某个分区的优先级从 5 调到 10解决了一次偶发的实时任务超时。2.3 内存分区的两种划分方式与校验方法内存划分有静态和动态两条路。静态划分最简单每个分区在设备树里写死一块物理区间Hypervisor 建立二级页表时直接映射虚拟机以为自己独占这段内存实际上它连隔壁的边都摸不到。ZVM 这类轻量架构基本都是静态划分因为它可预测出问题好定位。动态划分是靠 Hypervisor 维护一个内存池虚拟机启动时按需申请。好处是利用率高坏处是碎片化、失败路径多对嵌入式场景来说收益不抵复杂度。静态划分最大的风险是区间重叠。我吃过一次亏两个分区的reg手写的时候少看了一位第二块从 0x90000000 开始第一块是 0x80000000 加 0x10000000正好边界挨着我下意识以为是撞了查了半天发现没错。真正的问题在另一处——reserved-memory里有块固件保留区正好落在第二个分区的范围内启动时直接踩坏固件数据表现是串口输出一屏乱码后挂死。所以我现在养成了习惯写完设备树一定跑一遍脚本做三重校验分区区间两两不重叠、分区区间与 reserved-memory 不重叠、分区区间与 Hypervisor 自身代码段和数据段不重叠。这个校验用 dtc 把 DTB 反编译成文本再解析就行几十行 Python比事后调试省太多时间。dtc -I dtb -O dts -o /tmp/check.dts zvm.dtb python3 scripts/check_overlap.py /tmp/check.dts2.4 中断分配最容易翻车的地方中断是设备树配置里最容易出事的部分因为它是隐式冲突的。SPI 中断号在 SoC 里是全局资源两个分区如果都被分到同一个 SPI物理中断来了 Hypervisor 只能投递给其中一个另一个就永远收不到中断表现为驱动超时、设备无响应。我的做法是在设备树里给每个分区显式划一段中断号partition0 { zvm,interrupt-range 32 63; /* SPI 32 - 63 */ }; partition1 { zvm,interrupt-range 64 127; /* SPI 64 - 127 */ zvm,irq-map uart0 64, eth0 65, timer1 66; };zvm,interrupt-range是粗粒度的区间声明zvm,irq-map是细粒度的设备到中断号映射。生成虚拟机设备树时Hypervisor 会把物理中断号重映射到虚拟机内的虚拟中断号通常从 32 开始顺序编号这样虚拟机内的驱动看到的中断号和物理号不一样但逻辑一致。这里有个细节容易被忽略中断触发类型。物理设备树里interrupts属性带了触发类型标志比如0 64 4里的 4 表示电平触发高有效。重映射的时候这个标志必须一并带过去否则虚拟机配置成边沿触发物理上是电平就会出现中断丢失或者中断风暴。我在一个串口驱动上遇到过物理串口是电平触发重映射时把标志漏了虚拟机里每次接收都少最后一字节查了整整一天。2.5 属性裁剪的几个坑除了加属性删属性同样重要而且更容易忘。第一个必须删的是iommus。这个属性指向 SMMU 的 stream ID如果虚拟机设备树里还带着物理 stream ID而虚拟机又没法控制 SMMU结果就是设备 DMA 要么被 SMMU 拦住报错要么绕过检查直接写物理内存那就等于内存隔离白做了。我的规则是所有直通设备的iommus属性在生成虚拟机设备树时一律删除并在 Hypervisor 侧显式配置该设备的 stream ID 到分区内存的映射。第二个要处理的是/aliases节点。里面写的是设备路径别名跨分区引用会出问题。我通常只保留本分区内设备的别名其余全部删掉。第三个是/chosen里的bootargs。这个必须逐分区定制尤其是控制台参数。如果你给两个分区都配了consolettyAMA0两个系统会同时往同一个串口写输出交错在一起看起来像内核崩了实际只是日志打架。我的做法是分区 0 用真实串口分区 1 用虚拟串口或者干脆不输出靠 Hypervisor 提供的共享内存日志通道传出来。最后提醒一句设备树写完一定要反编译回文本人工看一遍。dtc 编译不报错不代表语义正确很多属性写错了照样能编过只是内核解析时忽略掉然后你就得到一个“看起来启动了但设备不能用”的虚拟机。3. 多虚拟机调度vCPU 与物理核的排班逻辑3.1 调度模型的选择可预测性优先调度器的设计目标决定了它的形态。服务器虚拟化追求吞吐量调度器会尽量把 CPU 塞满允许长尾延迟。嵌入式分区虚拟化追求的是可预测性我要能算出最坏情况下的响应时间哪怕平均性能差一点。基于这个前提ZVM 用的是固定优先级加时间片轮转的混合模型。每个分区有一个优先级高优先级分区的 vCPU 只要就绪就抢占低优先级的同优先级之间按时间片轮转保证公平。这套模型的好处是最坏响应时间可以算出来坏处是低优先级分区在负载高的时候会被饿所以配置时要留够余量。还有一种更严格的做法是时间分区类似航空电子领域的分区调度把时间轴切成固定长度的大周期每个分区在大周期内占一个固定的时间窗口窗口之间严格不重叠。这种模型的可预测性最强代价是灵活性差某个分区空闲时它的时间窗口也不能给别人用。ZVM 支持这两种模式通过设备树里的属性切换我在实时性要求极高的项目里用过时间分区效果确实好代价是 CPU 利用率上不去四核平均只有六成左右。3.2 核心数据结构与调度主循环调度器的核心是把 vCPU 当成调度实体。每个 vCPU 有自己的上下文包括通用寄存器、系统寄存器、浮点状态。物理核上维护一个就绪队列队列里是按优先级排序的 vCPU 节点。我用一段简化代码说明主循环的逻辑这段是伪代码但结构和我见过的实现基本一致struct vcpu { uint32_t id; uint32_t partition_id; uint32_t affinity; /* 绑定的物理核 */ int32_t priority; uint64_t slice_ns; /* 时间片长度 */ uint64_t remaining_ns; /* 本周期剩余时间片 */ struct vcpu_ctx ctx; /* 保存的寄存器上下文 */ struct list_head node; }; static void sched_tick(struct percpu_data *pcpu) { struct vcpu *curr pcpu-current; struct vcpu *next; curr-remaining_ns - TICK_NS; if (curr-remaining_ns 0 !pcpu-need_resched) return; next pick_next_vcpu(pcpu); /* 按优先级 轮转选下一个 */ if (next curr) { curr-remaining_ns curr-slice_ns; return; } vcpu_save_ctx(curr); vcpu_restore_ctx(next); /* 含 VMID/ASID 切换 */ pcpu-current next; next-remaining_ns next-slice_ns; }pick_next_vcpu里先按优先级挑优先级相同就看谁的剩余时间片归零了归零的排到队尾重新给满时间片。这个逻辑简单到几乎不会出错这也是我欣赏它的原因——调度器这种模块越简单越不容易在半夜出问题。上下文切换里最贵的不是保存寄存器是地址空间切换。如果每次切换都刷新 TLB开销会到微秒级对时间片只有几百微秒的场景来说完全不能接受。所以必须用 VMID 给 TLB 条目打标切换时只换 VMID 寄存器不刷 TLB旧条目留着等同一分区再被调度上来还能命中。3.3 时间片与最坏延迟的计算过程这部分是我在方案评审时被问得最多的索性把算法写清楚。假设一颗四核处理器主频 1.2GHz配置了三个分区分区 A 两个 vCPU 绑核 0、1优先级 10分区 B 一个 vCPU 绑核 2优先级 5分区 C 一个 vCPU 绑核 3优先级 5。这种一对一绑定的情况最省心每个物理核上只有一个 vCPU根本不需要时间片轮转切换只发生在中断处理时。真正需要算的是超配场景。假设分区 A 和分区 B 的 vCPU 都绑定在核 0 上A 优先级 10时间片 500 微秒B 优先级 5时间片 1000 微秒。B 的最坏调度延迟等于 A 跑满一个时间片的时间加上一次上下文切换开销最坏延迟 A 的时间片 切换开销 ≈ 500μs 5μs 505μs这个数字直接决定 B 里任务的响应性能。如果 B 是个实时控制环要求周期 1 毫秒那 505 微秒的抖动就吃掉一半余量几乎不能接受。解决办法要么降低 A 的时间片要么干脆把 A 和 B 绑到不同核上。再说超配更严重的情况。假设一个物理核上挂了四个同优先级 vCPU时间片都是 1 毫秒。那么一个完整的调度周期是 4 毫秒某个 vCPU 从被抢占到再次获得 CPU 的最长等待是 3 毫秒加上三次切换开销大约 3.015 毫秒。这意味着这个分区上的程序如果做 1 毫秒精度的定时会被系统性拖慢表现出来就是“定时器不准”。我一般的经验值是这样的实时性要求 1 毫秒以内的分区绝对不和别人共享物理核要求 10 毫秒以内的最多两个 vCPU 共享一核时间片控制在 200 微秒以内普通系统分区可以放宽四个共享一核也没关系。3.4 亲和性绑定与缓存局部性的权衡绑核是个双刃剑。绑定的好处是缓存局部性极好vCPU 一直在同一颗核上跑L1 缓存里的热数据不会被冲掉实测下来同样的负载绑定比不绑定能快 8% 到 15%具体看工作集大小。坏处是负载不均如果分区 A 的两个 vCPU 一个闲一个忙忙的那个也借不到别的核。我的做法是默认全绑定但对那些负载波动大的分区留一个“可迁移位”允许调度器在检测到负载不均衡时把它迁到空闲核。迁移的判断条件写得很保守必须连续若干个调度周期里目标核空闲率超过阈值才触发因为迁移一次的代价是重新预热缓存频繁迁移反而更慢。还有一个坑是中断亲和性要跟着 vCPU 走。物理中断如果被路由到一颗和 vCPU 不同的核上中断处理会在错误的核上执行要么产生跨核 IPI要么直接投错分区。配置时要把直通设备的中断亲和性设成和它的 vCPU 亲和性一致这个在设备树里可以声明也可以在运行时由 Hypervisor 强制设置。我倾向于后者因为设备树容易写漏。3.5 优先级与实时性的实际取舍优先级设计有个反直觉的点不是所有实时任务都需要高优先级。高优先级意味着它可以随时打断别人用多了整个系统的可预测性反而下降因为你很难算清楚所有高优先级任务的叠加效应。我通常按截止时间来排截止时间在百微秒级的给最高优先级并且独占核毫秒级的给中等优先级可以和别人共享核但时间片要短秒级的给最低优先级随便怎么排都行。分区数量控制在四个以内太多的话优先级层次拉不开调度器只能靠轮转那就退化成平均分配了。另外一个实践细节是优先级继承。如果低优先级分区持有共享内存的锁高优先级分区在等它就会出现优先级反转。ZVM 这种架构里共享内存通信很常见所以我在设计通信机制时就明确了一条共享内存的访问不加锁改用无锁环形队列彻底避开这个问题。环形队列的实现多花了两天但省掉了后面无穷无尽的死锁排查。4. 内存与中断虚拟化调度之外的两块硬骨头4.1 二级页表如何撑起隔离内存虚拟化的核心是二级地址翻译。虚拟机内的程序用的是虚拟地址先经过虚拟机自己的页表翻成“它以为的物理地址”再经过 Hypervisor 维护的二级页表翻成真正的物理地址。第二层翻译是隔离的关键虚拟机无论怎么折腾自己的页表都出不了 Hypervisor 给它划的那块区间。实现上就是把二级页表的基地址写进系统寄存器每次上下文切换时换成对应分区的基地址。翻译过程由硬件完成不需要软件介入所以性能损失很小。真正需要注意的是 TLB 一致性改了二级页表之后必须发无效化指令而且无效化的范围要对发多了性能差发少了会出现脏映射。我在调试时遇到过一个经典问题某个分区的镜像明明更新了跑起来还是旧代码。排查了半天发现是二级页表改了但没刷 TLBCPU 拿的还是缓存里的旧映射。这类问题在开发阶段频繁出现我后来在页表修改的接口里统一加了一次全局无效化性能损失可以忽略但省掉了大量诡异 bug。共享内存的处理要单独说。两个分区通信最简单的方式是划一块物理内存在两边都映射一头读一头写。但这块内存必须绕开二级页表的保护做法是标记为共享属性两边都可读可写且不被任何一方独占。风险是两个分区同时写会踩数据所以一定要配合前面说的无锁队列或者硬件信号量。4.2 中断注入的完整路径中断虚拟化是延迟敏感的部分路径长短直接影响实时性能。物理中断来了先到 Hypervisor 的中断处理入口它读中断控制器拿到中断号查映射表找到归属分区然后把中断注入到该分区的虚拟中断控制器最后虚拟中断控制器触发 vCPU 的虚拟中断线。注入这个动作有硬件加速和软件模拟两条路。硬件加速靠的是中断控制器自带的虚拟化扩展Hypervisor 往一个专门的寄存器里写一条记录硬件自动完成投递开销在百纳秒级。软件模拟就是 Hypervisor 在内存里维护一个虚拟中断控制器状态改完之后再想办法让 vCPU 感知到开销大得多而且容易出竞态。我用的一律是硬件路径代价是要处理一个限制硬件提供的注入槽位数量有限通常只有几个。如果短时间内来一堆中断槽位不够用就必须排队等槽位释放。这个“等槽位”的过程如果处理不好会造成中断丢失。正确的做法是槽位满时不丢中断而是挂到一个软件待注入队列里等槽位空出来再补同时还要处理同一个中断在排队期间又被触发的情况做合并。实测数据参考一下一个物理中断从到达 Hypervisor 到虚拟机内中断服务程序开始执行走硬件注入路径大约 3 到 8 微秒具体数值和处理器主频、中断控制器版本有关。走软件模拟路径则在 20 微秒以上。对于要求几十微秒响应的场景这个差距是决定性的。4.3 定时器虚拟化的特殊处理定时器值得单独说一句因为它和调度器耦合最紧。每个虚拟机都需要自己的定时器来维持系统节拍如果让它们都去操作物理定时器会互相踩。所以 Hypervisor 要给每个虚拟机维护一个虚拟计数器基于物理计数器加偏移量计算。偏移量的处理有个细节虚拟机的计数器在它被调度出去的那段时间里应该是“停”的还是“继续走”取决于虚拟机的预期。如果虚拟机里跑的是实时系统它期待时间连续那就继续走代价是它被调度回来时会发现时间跳变可能一次性触发一堆超时。如果跑的是普通系统停掉更符合直觉。ZVM 里这个可以按分区配置我在实时分区上选了连续走并且在调度器里做了补偿被抢占期间累积的定时器事件在恢复时合并成一次投递避免中断风暴。5. 实操过程从零跑起两个虚拟机5.1 环境准备与工具链这套流程我在多个项目上重复过整理成可以照着做的顺序。工具链用交叉编译版本目标是 64 位 ARM 架构裸机环境。我一般固定用某个版本不轻易升级因为 Hypervisor 这种直接操作硬件的代码对编译器优化行为很敏感换版本可能引入莫名其妙的运行时问题。需要准备的组件有Hypervisor 源码、至少两个虚拟机镜像一个裸机测试程序加一个通用系统镜像、设备树编译器、镜像打包脚本。虚拟机镜像建议第一个先用裸机程序因为它输出简单出问题好定位等裸机跑通了再上复杂系统。export CROSS_COMPILEaarch64-none-elf- export ARCHarm64 make zvm_defconfig make -j8编译产物里最关键的三个文件是 Hypervisor 镜像、各虚拟机镜像、以及一份合并后的设备树。镜像打包脚本负责把这几样按约定的内存布局摆好生成一个可以烧录的镜像文件。5.2 内存布局与镜像打包布局规划是这一步的重点。我习惯从高地址往低地址排因为低地址通常被引导程序占用。给一个实际用过的布局区域起始地址大小说明引导程序0x000000002MB板载固件Hypervisor0x002000001MB代码加数据分区 0 镜像0x802000004MB裸机实时程序分区 0 内存0x80000000256MB含镜像与堆栈分区 1 镜像0x9020000064MB通用系统分区 1 内存0x90000000512MB含镜像与文件系统共享内存0xA00000001MB双向环形队列注意分区 0 的镜像地址落在它自己的内存区间内这是必须的因为镜像加载后虚拟机要用自己的页表访问它如果超出区间会被二级页表拦住导致启动失败。我第一次配的时候就犯了这个错镜像放到了分区内存区之外启动瞬间就挂在页表错误上串口只吐了一行异常信息。打包脚本的核心就是把各段二进制用 dd 写到镜像文件的对应偏移dd ifzvm.bin offlash.img bs1M seek2 convnotrunc dd ifguest0.bin offlash.img bs1M seek128 convnotrunc dd ifguest1.bin offlash.img bs1M seek256 convnotrunc5.3 启动流程与日志验证上电后的流程是这样的引导程序加载镜像跳转到 Hypervisor 入口Hypervisor 初始化异常向量、页表、中断控制器然后解析设备树解析完成后给每个分区生成设备树副本并写入其内存接着初始化调度器创建各分区的 vCPU最后启动第一个分区进入调度循环。启动日志是我判断成功与否的第一手依据。正常的日志应该能看到 Hypervisor 版本信息、物理内存探测结果、每个分区的配置回显、二级页表建立完成、然后依次是两个分区的启动输出。如果日志停在“解析设备树”之后没有下文八成是分区配置有问题如果看到页表建立完成但没有分区输出多半是入口地址跳错了。验证环节我一般跑三个检查。第一是看两个分区的串口输出是否独立各自打印自己的标识交错出现是正常的但不能有乱码。第二是在每个分区里跑内存读写测试往自己的地址空间边界附近写数据确认不越界。第三是跑一个延时测量程序统计调度抖动和前面算的理论值对一下。5.4 性能数据与预期对照给一组我在四核 1.2GHz 平台上测到的参考值具体数值因平台而异但量级有参考意义。分区间上下文切换开销大约是 4 到 6 微秒其中寄存器保存恢复占小头缓存污染占大头。中断注入延迟 3 到 8 微秒。内存访问因为多了一层翻译实测比原生慢 2% 到 5%主要是 TLB 未命中率上升导致。两个分区同时跑满时各自的算力大约是独占时的 92% 到 95%损失来自共享缓存争用和内存带宽。这些数字如果和你的预期差太多先别怀疑架构去查设备树配置和缓存属性。我遇到过一次性能只有预期六成的情况最后发现是二级页表里把设备内存区映射成了可缓存导致每次访问都走缓存一致性流程慢得离谱。改成不可缓存之后立刻恢复正常。6. 常见问题与排查技巧实录6.1 启动阶段的典型故障启动阶段的问题占了我在这个方向上调过的 bug 的一大半而且症状都很像——没输出或者输出几行就停。这里列几个我踩过的。第一个是虚拟机完全无输出。可能原因有三个层次镜像没加载到正确地址、入口地址配错、设备树里控制台节点被裁掉了。排查顺序是从外往里先用调试器读内存确认镜像真的在那儿再确认入口地址的指令是合法的最后检查设备树的/chosen节点里stdout-path指向的设备在当前分区是否可见。第二个是输出乱码。这个问题有意思通常不是串口波特率错而是虚拟机的设备树里串口时钟频率属性不对。虚拟机看到的是物理串口寄存器操作是直通的但时钟频率如果配错算出来的分频值就错波特率自然不对。解决方法是把物理设备树里的时钟相关属性原样保留不要裁剪。第三个是启动到一半跳飞。这种八成是内存越界或者二级页表映射不全。我一般的做法是在 Hypervisor 里打开页表错误日志看异常发生的地址落在哪个区间一看就知道是哪个分区的配置有问题。6.2 运行期的抖动与性能问题运行期的问题更隐蔽因为系统在跑只是表现不符合预期。最常见的是周期性抖动。某个分区的任务本该每毫秒执行一次实际间隔在 1 毫秒到 1.8 毫秒之间波动。原因通常是调度抢占另一个分区的 vCPU 在同一颗物理核上跑抢占造成了延迟。解决办法前面说过要么绑核要么缩短抢占者的时间片。第二个是偶发的长时间停顿几百毫秒级别。这种一般不是调度问题而是某个操作触发了大量页表无效化或者缓存维护操作。我在一次调试中定位到是分区在频繁映射解映射共享内存每次操作都做全局 TLB 刷累积起来就是明显的停顿。改成局部刷之后问题消失。第三个是中断丢失。表现是设备偶尔不响应重启就好。这类问题要查中断注入的槽位管理尤其是高中断频率场景下槽位满时的排队逻辑有没有漏洞。我的做法是在 Hypervisor 里加计数器统计槽位满的次数和丢弃的次数跑压力测试看这两个数字只要丢弃不为零就必须修。6.3 排查速查表把上面这些整理成表出问题时按顺序过一遍能省不少时间现象优先排查项常用手段虚拟机无任何输出镜像地址、入口地址、控制台设备可见性调试器读内存、反汇编入口输出乱码串口时钟属性、波特率配置对比物理与虚拟设备树差异启动中途异常二级页表映射范围、内存区间重叠打开页表错误日志看故障地址运行期周期抖动vCPU 抢占、时间片长度统计调度延迟分布、调整绑核偶发长停顿TLB 全局刷新、缓存维护操作改为局部刷新、减少映射变更设备偶尔无响应中断槽位耗尽、中断号冲突加计数器统计丢弃次数性能低于预期内存属性配置、缓存策略检查页表属性位、对比原生性能最后再分享一个我觉得最值钱的习惯给 Hypervisor 加一个轻量的跟踪缓冲区把每次上下文切换、每次中断注入、每次页表修改都打上时间戳记进去出问题时把缓冲区 dump 出来。这个机制占用的资源极少但它能让你从“猜”变成“看”。我在一个偶发的调度异常上就是靠它定位的——跟踪记录显示每次异常前都有一笔来自某个特定地址的页表修改顺着这个地址找到了一个第三方驱动的越界写。这套东西搭起来的前期投入不小设备树的坑、调度的坑、中断的坑每一个都得花时间趟。但趟完之后你会发现同一颗芯片能干的事多了一倍而且各个系统之间互不干扰现场的故障半径从整机缩小到单个分区。我个人在实际操作中的体会是前期在设备树校验和跟踪机制上多花的两三天会在后面的调试里十倍地还回来别省这个工夫。 
长河君 · 2026/10/28 15:21:04 · 阅读 1.2k ZVM轻量级分区虚拟化：设备树资源划分与vCPU调度实践
在嵌入式圈子里干了这些年有一个变化是绕不开的以前一颗多核 SoC 上跑一个系统就够用现在越来越多的设备要求同一颗芯片上同时跑实时控制、人机界面、通信网关甚至一段裸机安全监控彼此还不能互相干扰。ZVM 就是冲着这个需求来的——一个面向嵌入式与边缘设备的轻量级分区虚拟化架构它把一颗多核 SoC 切成若干互相隔离的执行环境每个环境跑自己的操作系统或裸机程序靠设备树描述硬件归属靠一个极简的 vCPU 调度器把物理核分给各个虚拟机。这篇文章我不打算讲概念科普而是把 ZVM 这类架构里最难啃的两块拆开设备树怎么把一个物理硬件“分家”分干净以及多虚拟机跑起来之后 vCPU 怎么在物理核上排班。如果你正在做多系统合一的方案评估或者手上已经有一块开发板想验证分区虚拟化又或者你只是好奇一颗芯片怎么被切成三份还不打架下面的内容应该都能直接拿去参考。文中涉及的具体节点名、属性名是我按常见实践补的写法不同实现会有差异但设计逻辑是通用的。1. 架构选型为什么要在设备树之上做一层轻量 Hypervisor1.1 多系统合一是被成本逼出来的先说我遇到过的真实场景类型某工业网关项目需求是同一块板子上同时具备三件事——一个毫秒级响应的实时控制循环、一个带触屏的图形界面、一个负责协议转换和日志上报的通用系统。最直接的做法是双芯片实时那颗用 MCU界面和网关用一颗应用处理器中间走 SPI 或串口通信。选型会上算过账双芯片方案 BOM 多出十几块钱PCB 面积多占一圈还要多一路电源和时钟量产几十万台就是一笔不小的数字。另一个备选是 AMP也就是非对称多处理四颗核两颗跑实时系统两颗跑 Linux各自从固定地址启动中间靠共享内存通信。这个方案便宜但它有个致命弱点——隔离全靠自觉。裸机那边指针越界写进了 Linux 的内存区Linux 直接崩而且你很难查。更麻烦的是外设争抢两个系统都想初始化同一个串口控制器谁先谁后没有仲裁机制。分区虚拟化就是在这两者之间找到的平衡点硬件成本跟 AMP 一样隔离性接近双芯片。代价是要多一层软件以及随之而来的调试复杂度。ZVM 这类架构的核心价值就在这儿它不追求通用专攻“把硬件安全地切开”这件事。1.2 “轻量”到底轻在哪些地方很多朋友第一次接触这类架构会问它和跑在服务器上的那套通用虚拟化有什么区别区别大了主要集中在三点。第一是不做设备模拟。服务器虚拟化要模拟一块完整的网卡、一块 SCSI 控制器因为虚拟机里的操作系统期待见到标准设备。ZVM 这类方案不干这种事它走的是直通路线物理串口就是串口物理网卡就是网卡虚拟机直接访问寄存器Hypervisor 只在页表层面把这些 MMIO 区域划给它。省掉了模拟层代码量骤降访问延迟也接近原生。第二是没有完整的二级调度。通用虚拟化里虚拟机内的进程调度和 Hypervisor 的 vCPU 调度是两层独立机制配合起来很复杂。嵌入式场景下虚拟机数量通常是个位数静态分配加简单的时间片轮转就够用调度器可以压缩到千行以内。第三是启动路径极短。从引导程序交出控制权到第一个虚拟机开始跑整个流程在毫秒级。这在工业设备上很重要因为有些场景要求上电后极短时间内进入安全状态。我做过一次横向对比把三类方案的特性摊在表格里选型会上最好用维度双芯片方案AMP 裸跑ZVM 分区虚拟化硬件成本高低低内存隔离物理隔离无二级页表强隔离外设争抢不存在需人工约定设备树静态分配单点故障影响局部全局局部调试复杂度低中高启动时间秒级百毫秒级毫秒级1.3 整体分层与各组件的职责边界ZVM 的结构可以粗分成四层从上往下是管理接口、调度与虚拟化核心、配置解析、引导层。引导层负责把 Hypervisor 镜像和各虚拟机的镜像搬到内存里的正确位置然后跳转到 Hypervisor 入口。这一层通常由板载引导程序完成也可能是 Hypervisor 自带的一个小 loader。配置解析层就是设备树处理模块。它在 Hypervisor 初始化时读取物理设备树按分区规则裁剪出一份份“虚拟机视角”的设备树副本塞进各虚拟机的内存区。这一层的输出直接决定了后面虚拟机看到的世界长什么样。虚拟化核心包括三块CPU 虚拟化负责陷入陷出和系统寄存器上下文切换内存虚拟化维护二级页表中断虚拟化管理物理中断到虚拟中断的映射与注入。调度层是这个架构里唯一一个“纯软件策略”模块它决定某一时刻哪颗物理核跑哪个 vCPU。它的输入是设备树里给每个分区配的 CPU 亲和性和权重输出是一次次上下文切换。组件之间耦合最紧的是配置解析和虚拟化核心。设备树里写错一个地址表现出来可能是内存虚拟化阶段的映射失败也可能是虚拟机启动到一半跳飞到某个莫名其妙的地址。这也是为什么我在下面的章节里把设备树单独拎出来讲一大段。2. 设备树配置把硬件资源分家的第一现场2.1 设备树在虚拟化场景下的角色变化在普通的裸机或单系统 Linux 里设备树的作用是“告诉内核板子上有什么”。到了虚拟化场景它的角色变成了“告诉每个虚拟机它能用什么”这个转变带来的复杂度是数量级的。一份物理设备树进来至少要产出三份视图。第一份是 Hypervisor 自己的视图它需要知道全部硬件尤其是中断控制器、定时器、串口这些它要直接管理的设备。第二份和第三份是各虚拟机的视图每份都是物理设备树的一个子集加改写。改写规则很讲究。地址要改因为虚拟机看到的内存起始地址和物理地址不一样中断号要改因为物理中断号是全局唯一的而每个虚拟机内部都希望从中断号 32 开始数那些虚拟机不该看见的节点必须删掉比如指向别的分区内存的 reserved-memory 节点留着就是信息泄露还可能被误用。为什么用设备树而不是编译期硬编码因为板级差异太大。同一个 Hypervisor 二进制换一块板子只换 DTB 文件代码一行不动。这个好处在项目后期特别明显客户要换一款 SoC你只需要重写设备树不用重新走一遍回归测试。2.2 分区容器节点怎么写我给一个相对完整的写法示例这是我在项目里用过的结构属性名做了通用化处理/ { #address-cells 2; #size-cells 2; zvm: zvm-config { compatible zvm,partition-config; #address-cells 1; #size-cells 1; partition0 { zvm,id 0; zvm,name rtos; zvm,cpus 0 1; zvm,entry 0x0 0x80200000; reg 0x0 0x80000000 0x0 0x10000000; /* 256MB */ zvm,priority 10; zvm,time-slice-us 500; status okay; }; partition1 { zvm,id 1; zvm,name linux; zvm,cpus 2 3; zvm,entry 0x0 0x90200000; reg 0x0 0x90000000 0x0 0x20000000; /* 512MB */ zvm,priority 5; zvm,time-slice-us 1000; status okay; }; }; };这里几个属性需要解释。zvm,cpus是 vCPU 到物理核的亲和性映射写0 1表示这个分区的两个 vCPU 固定跑在物理核 0 和 1 上。zvm,entry是这个分区镜像的入口物理地址Hypervisor 启动该分区时就是跳到这个地址。reg描述分配给它的物理内存区间注意这个区间必须在物理内存范围内且不能和其他分区重叠这一点靠人工保证我后面会讲怎么校验。zvm,priority和zvm,time-slice-us是给调度器看的。这两个参数放在设备树里而不是编译进代码好处是现场调试时不用重编译改 DTB 重启就行。我在一个项目里就靠这个特性把某个分区的优先级从 5 调到 10解决了一次偶发的实时任务超时。2.3 内存分区的两种划分方式与校验方法内存划分有静态和动态两条路。静态划分最简单每个分区在设备树里写死一块物理区间Hypervisor 建立二级页表时直接映射虚拟机以为自己独占这段内存实际上它连隔壁的边都摸不到。ZVM 这类轻量架构基本都是静态划分因为它可预测出问题好定位。动态划分是靠 Hypervisor 维护一个内存池虚拟机启动时按需申请。好处是利用率高坏处是碎片化、失败路径多对嵌入式场景来说收益不抵复杂度。静态划分最大的风险是区间重叠。我吃过一次亏两个分区的reg手写的时候少看了一位第二块从 0x90000000 开始第一块是 0x80000000 加 0x10000000正好边界挨着我下意识以为是撞了查了半天发现没错。真正的问题在另一处——reserved-memory里有块固件保留区正好落在第二个分区的范围内启动时直接踩坏固件数据表现是串口输出一屏乱码后挂死。所以我现在养成了习惯写完设备树一定跑一遍脚本做三重校验分区区间两两不重叠、分区区间与 reserved-memory 不重叠、分区区间与 Hypervisor 自身代码段和数据段不重叠。这个校验用 dtc 把 DTB 反编译成文本再解析就行几十行 Python比事后调试省太多时间。dtc -I dtb -O dts -o /tmp/check.dts zvm.dtb python3 scripts/check_overlap.py /tmp/check.dts2.4 中断分配最容易翻车的地方中断是设备树配置里最容易出事的部分因为它是隐式冲突的。SPI 中断号在 SoC 里是全局资源两个分区如果都被分到同一个 SPI物理中断来了 Hypervisor 只能投递给其中一个另一个就永远收不到中断表现为驱动超时、设备无响应。我的做法是在设备树里给每个分区显式划一段中断号partition0 { zvm,interrupt-range 32 63; /* SPI 32 - 63 */ }; partition1 { zvm,interrupt-range 64 127; /* SPI 64 - 127 */ zvm,irq-map uart0 64, eth0 65, timer1 66; };zvm,interrupt-range是粗粒度的区间声明zvm,irq-map是细粒度的设备到中断号映射。生成虚拟机设备树时Hypervisor 会把物理中断号重映射到虚拟机内的虚拟中断号通常从 32 开始顺序编号这样虚拟机内的驱动看到的中断号和物理号不一样但逻辑一致。这里有个细节容易被忽略中断触发类型。物理设备树里interrupts属性带了触发类型标志比如0 64 4里的 4 表示电平触发高有效。重映射的时候这个标志必须一并带过去否则虚拟机配置成边沿触发物理上是电平就会出现中断丢失或者中断风暴。我在一个串口驱动上遇到过物理串口是电平触发重映射时把标志漏了虚拟机里每次接收都少最后一字节查了整整一天。2.5 属性裁剪的几个坑除了加属性删属性同样重要而且更容易忘。第一个必须删的是iommus。这个属性指向 SMMU 的 stream ID如果虚拟机设备树里还带着物理 stream ID而虚拟机又没法控制 SMMU结果就是设备 DMA 要么被 SMMU 拦住报错要么绕过检查直接写物理内存那就等于内存隔离白做了。我的规则是所有直通设备的iommus属性在生成虚拟机设备树时一律删除并在 Hypervisor 侧显式配置该设备的 stream ID 到分区内存的映射。第二个要处理的是/aliases节点。里面写的是设备路径别名跨分区引用会出问题。我通常只保留本分区内设备的别名其余全部删掉。第三个是/chosen里的bootargs。这个必须逐分区定制尤其是控制台参数。如果你给两个分区都配了consolettyAMA0两个系统会同时往同一个串口写输出交错在一起看起来像内核崩了实际只是日志打架。我的做法是分区 0 用真实串口分区 1 用虚拟串口或者干脆不输出靠 Hypervisor 提供的共享内存日志通道传出来。最后提醒一句设备树写完一定要反编译回文本人工看一遍。dtc 编译不报错不代表语义正确很多属性写错了照样能编过只是内核解析时忽略掉然后你就得到一个“看起来启动了但设备不能用”的虚拟机。3. 多虚拟机调度vCPU 与物理核的排班逻辑3.1 调度模型的选择可预测性优先调度器的设计目标决定了它的形态。服务器虚拟化追求吞吐量调度器会尽量把 CPU 塞满允许长尾延迟。嵌入式分区虚拟化追求的是可预测性我要能算出最坏情况下的响应时间哪怕平均性能差一点。基于这个前提ZVM 用的是固定优先级加时间片轮转的混合模型。每个分区有一个优先级高优先级分区的 vCPU 只要就绪就抢占低优先级的同优先级之间按时间片轮转保证公平。这套模型的好处是最坏响应时间可以算出来坏处是低优先级分区在负载高的时候会被饿所以配置时要留够余量。还有一种更严格的做法是时间分区类似航空电子领域的分区调度把时间轴切成固定长度的大周期每个分区在大周期内占一个固定的时间窗口窗口之间严格不重叠。这种模型的可预测性最强代价是灵活性差某个分区空闲时它的时间窗口也不能给别人用。ZVM 支持这两种模式通过设备树里的属性切换我在实时性要求极高的项目里用过时间分区效果确实好代价是 CPU 利用率上不去四核平均只有六成左右。3.2 核心数据结构与调度主循环调度器的核心是把 vCPU 当成调度实体。每个 vCPU 有自己的上下文包括通用寄存器、系统寄存器、浮点状态。物理核上维护一个就绪队列队列里是按优先级排序的 vCPU 节点。我用一段简化代码说明主循环的逻辑这段是伪代码但结构和我见过的实现基本一致struct vcpu { uint32_t id; uint32_t partition_id; uint32_t affinity; /* 绑定的物理核 */ int32_t priority; uint64_t slice_ns; /* 时间片长度 */ uint64_t remaining_ns; /* 本周期剩余时间片 */ struct vcpu_ctx ctx; /* 保存的寄存器上下文 */ struct list_head node; }; static void sched_tick(struct percpu_data *pcpu) { struct vcpu *curr pcpu-current; struct vcpu *next; curr-remaining_ns - TICK_NS; if (curr-remaining_ns 0 !pcpu-need_resched) return; next pick_next_vcpu(pcpu); /* 按优先级 轮转选下一个 */ if (next curr) { curr-remaining_ns curr-slice_ns; return; } vcpu_save_ctx(curr); vcpu_restore_ctx(next); /* 含 VMID/ASID 切换 */ pcpu-current next; next-remaining_ns next-slice_ns; }pick_next_vcpu里先按优先级挑优先级相同就看谁的剩余时间片归零了归零的排到队尾重新给满时间片。这个逻辑简单到几乎不会出错这也是我欣赏它的原因——调度器这种模块越简单越不容易在半夜出问题。上下文切换里最贵的不是保存寄存器是地址空间切换。如果每次切换都刷新 TLB开销会到微秒级对时间片只有几百微秒的场景来说完全不能接受。所以必须用 VMID 给 TLB 条目打标切换时只换 VMID 寄存器不刷 TLB旧条目留着等同一分区再被调度上来还能命中。3.3 时间片与最坏延迟的计算过程这部分是我在方案评审时被问得最多的索性把算法写清楚。假设一颗四核处理器主频 1.2GHz配置了三个分区分区 A 两个 vCPU 绑核 0、1优先级 10分区 B 一个 vCPU 绑核 2优先级 5分区 C 一个 vCPU 绑核 3优先级 5。这种一对一绑定的情况最省心每个物理核上只有一个 vCPU根本不需要时间片轮转切换只发生在中断处理时。真正需要算的是超配场景。假设分区 A 和分区 B 的 vCPU 都绑定在核 0 上A 优先级 10时间片 500 微秒B 优先级 5时间片 1000 微秒。B 的最坏调度延迟等于 A 跑满一个时间片的时间加上一次上下文切换开销最坏延迟 A 的时间片 切换开销 ≈ 500μs 5μs 505μs这个数字直接决定 B 里任务的响应性能。如果 B 是个实时控制环要求周期 1 毫秒那 505 微秒的抖动就吃掉一半余量几乎不能接受。解决办法要么降低 A 的时间片要么干脆把 A 和 B 绑到不同核上。再说超配更严重的情况。假设一个物理核上挂了四个同优先级 vCPU时间片都是 1 毫秒。那么一个完整的调度周期是 4 毫秒某个 vCPU 从被抢占到再次获得 CPU 的最长等待是 3 毫秒加上三次切换开销大约 3.015 毫秒。这意味着这个分区上的程序如果做 1 毫秒精度的定时会被系统性拖慢表现出来就是“定时器不准”。我一般的经验值是这样的实时性要求 1 毫秒以内的分区绝对不和别人共享物理核要求 10 毫秒以内的最多两个 vCPU 共享一核时间片控制在 200 微秒以内普通系统分区可以放宽四个共享一核也没关系。3.4 亲和性绑定与缓存局部性的权衡绑核是个双刃剑。绑定的好处是缓存局部性极好vCPU 一直在同一颗核上跑L1 缓存里的热数据不会被冲掉实测下来同样的负载绑定比不绑定能快 8% 到 15%具体看工作集大小。坏处是负载不均如果分区 A 的两个 vCPU 一个闲一个忙忙的那个也借不到别的核。我的做法是默认全绑定但对那些负载波动大的分区留一个“可迁移位”允许调度器在检测到负载不均衡时把它迁到空闲核。迁移的判断条件写得很保守必须连续若干个调度周期里目标核空闲率超过阈值才触发因为迁移一次的代价是重新预热缓存频繁迁移反而更慢。还有一个坑是中断亲和性要跟着 vCPU 走。物理中断如果被路由到一颗和 vCPU 不同的核上中断处理会在错误的核上执行要么产生跨核 IPI要么直接投错分区。配置时要把直通设备的中断亲和性设成和它的 vCPU 亲和性一致这个在设备树里可以声明也可以在运行时由 Hypervisor 强制设置。我倾向于后者因为设备树容易写漏。3.5 优先级与实时性的实际取舍优先级设计有个反直觉的点不是所有实时任务都需要高优先级。高优先级意味着它可以随时打断别人用多了整个系统的可预测性反而下降因为你很难算清楚所有高优先级任务的叠加效应。我通常按截止时间来排截止时间在百微秒级的给最高优先级并且独占核毫秒级的给中等优先级可以和别人共享核但时间片要短秒级的给最低优先级随便怎么排都行。分区数量控制在四个以内太多的话优先级层次拉不开调度器只能靠轮转那就退化成平均分配了。另外一个实践细节是优先级继承。如果低优先级分区持有共享内存的锁高优先级分区在等它就会出现优先级反转。ZVM 这种架构里共享内存通信很常见所以我在设计通信机制时就明确了一条共享内存的访问不加锁改用无锁环形队列彻底避开这个问题。环形队列的实现多花了两天但省掉了后面无穷无尽的死锁排查。4. 内存与中断虚拟化调度之外的两块硬骨头4.1 二级页表如何撑起隔离内存虚拟化的核心是二级地址翻译。虚拟机内的程序用的是虚拟地址先经过虚拟机自己的页表翻成“它以为的物理地址”再经过 Hypervisor 维护的二级页表翻成真正的物理地址。第二层翻译是隔离的关键虚拟机无论怎么折腾自己的页表都出不了 Hypervisor 给它划的那块区间。实现上就是把二级页表的基地址写进系统寄存器每次上下文切换时换成对应分区的基地址。翻译过程由硬件完成不需要软件介入所以性能损失很小。真正需要注意的是 TLB 一致性改了二级页表之后必须发无效化指令而且无效化的范围要对发多了性能差发少了会出现脏映射。我在调试时遇到过一个经典问题某个分区的镜像明明更新了跑起来还是旧代码。排查了半天发现是二级页表改了但没刷 TLBCPU 拿的还是缓存里的旧映射。这类问题在开发阶段频繁出现我后来在页表修改的接口里统一加了一次全局无效化性能损失可以忽略但省掉了大量诡异 bug。共享内存的处理要单独说。两个分区通信最简单的方式是划一块物理内存在两边都映射一头读一头写。但这块内存必须绕开二级页表的保护做法是标记为共享属性两边都可读可写且不被任何一方独占。风险是两个分区同时写会踩数据所以一定要配合前面说的无锁队列或者硬件信号量。4.2 中断注入的完整路径中断虚拟化是延迟敏感的部分路径长短直接影响实时性能。物理中断来了先到 Hypervisor 的中断处理入口它读中断控制器拿到中断号查映射表找到归属分区然后把中断注入到该分区的虚拟中断控制器最后虚拟中断控制器触发 vCPU 的虚拟中断线。注入这个动作有硬件加速和软件模拟两条路。硬件加速靠的是中断控制器自带的虚拟化扩展Hypervisor 往一个专门的寄存器里写一条记录硬件自动完成投递开销在百纳秒级。软件模拟就是 Hypervisor 在内存里维护一个虚拟中断控制器状态改完之后再想办法让 vCPU 感知到开销大得多而且容易出竞态。我用的一律是硬件路径代价是要处理一个限制硬件提供的注入槽位数量有限通常只有几个。如果短时间内来一堆中断槽位不够用就必须排队等槽位释放。这个“等槽位”的过程如果处理不好会造成中断丢失。正确的做法是槽位满时不丢中断而是挂到一个软件待注入队列里等槽位空出来再补同时还要处理同一个中断在排队期间又被触发的情况做合并。实测数据参考一下一个物理中断从到达 Hypervisor 到虚拟机内中断服务程序开始执行走硬件注入路径大约 3 到 8 微秒具体数值和处理器主频、中断控制器版本有关。走软件模拟路径则在 20 微秒以上。对于要求几十微秒响应的场景这个差距是决定性的。4.3 定时器虚拟化的特殊处理定时器值得单独说一句因为它和调度器耦合最紧。每个虚拟机都需要自己的定时器来维持系统节拍如果让它们都去操作物理定时器会互相踩。所以 Hypervisor 要给每个虚拟机维护一个虚拟计数器基于物理计数器加偏移量计算。偏移量的处理有个细节虚拟机的计数器在它被调度出去的那段时间里应该是“停”的还是“继续走”取决于虚拟机的预期。如果虚拟机里跑的是实时系统它期待时间连续那就继续走代价是它被调度回来时会发现时间跳变可能一次性触发一堆超时。如果跑的是普通系统停掉更符合直觉。ZVM 里这个可以按分区配置我在实时分区上选了连续走并且在调度器里做了补偿被抢占期间累积的定时器事件在恢复时合并成一次投递避免中断风暴。5. 实操过程从零跑起两个虚拟机5.1 环境准备与工具链这套流程我在多个项目上重复过整理成可以照着做的顺序。工具链用交叉编译版本目标是 64 位 ARM 架构裸机环境。我一般固定用某个版本不轻易升级因为 Hypervisor 这种直接操作硬件的代码对编译器优化行为很敏感换版本可能引入莫名其妙的运行时问题。需要准备的组件有Hypervisor 源码、至少两个虚拟机镜像一个裸机测试程序加一个通用系统镜像、设备树编译器、镜像打包脚本。虚拟机镜像建议第一个先用裸机程序因为它输出简单出问题好定位等裸机跑通了再上复杂系统。export CROSS_COMPILEaarch64-none-elf- export ARCHarm64 make zvm_defconfig make -j8编译产物里最关键的三个文件是 Hypervisor 镜像、各虚拟机镜像、以及一份合并后的设备树。镜像打包脚本负责把这几样按约定的内存布局摆好生成一个可以烧录的镜像文件。5.2 内存布局与镜像打包布局规划是这一步的重点。我习惯从高地址往低地址排因为低地址通常被引导程序占用。给一个实际用过的布局区域起始地址大小说明引导程序0x000000002MB板载固件Hypervisor0x002000001MB代码加数据分区 0 镜像0x802000004MB裸机实时程序分区 0 内存0x80000000256MB含镜像与堆栈分区 1 镜像0x9020000064MB通用系统分区 1 内存0x90000000512MB含镜像与文件系统共享内存0xA00000001MB双向环形队列注意分区 0 的镜像地址落在它自己的内存区间内这是必须的因为镜像加载后虚拟机要用自己的页表访问它如果超出区间会被二级页表拦住导致启动失败。我第一次配的时候就犯了这个错镜像放到了分区内存区之外启动瞬间就挂在页表错误上串口只吐了一行异常信息。打包脚本的核心就是把各段二进制用 dd 写到镜像文件的对应偏移dd ifzvm.bin offlash.img bs1M seek2 convnotrunc dd ifguest0.bin offlash.img bs1M seek128 convnotrunc dd ifguest1.bin offlash.img bs1M seek256 convnotrunc5.3 启动流程与日志验证上电后的流程是这样的引导程序加载镜像跳转到 Hypervisor 入口Hypervisor 初始化异常向量、页表、中断控制器然后解析设备树解析完成后给每个分区生成设备树副本并写入其内存接着初始化调度器创建各分区的 vCPU最后启动第一个分区进入调度循环。启动日志是我判断成功与否的第一手依据。正常的日志应该能看到 Hypervisor 版本信息、物理内存探测结果、每个分区的配置回显、二级页表建立完成、然后依次是两个分区的启动输出。如果日志停在“解析设备树”之后没有下文八成是分区配置有问题如果看到页表建立完成但没有分区输出多半是入口地址跳错了。验证环节我一般跑三个检查。第一是看两个分区的串口输出是否独立各自打印自己的标识交错出现是正常的但不能有乱码。第二是在每个分区里跑内存读写测试往自己的地址空间边界附近写数据确认不越界。第三是跑一个延时测量程序统计调度抖动和前面算的理论值对一下。5.4 性能数据与预期对照给一组我在四核 1.2GHz 平台上测到的参考值具体数值因平台而异但量级有参考意义。分区间上下文切换开销大约是 4 到 6 微秒其中寄存器保存恢复占小头缓存污染占大头。中断注入延迟 3 到 8 微秒。内存访问因为多了一层翻译实测比原生慢 2% 到 5%主要是 TLB 未命中率上升导致。两个分区同时跑满时各自的算力大约是独占时的 92% 到 95%损失来自共享缓存争用和内存带宽。这些数字如果和你的预期差太多先别怀疑架构去查设备树配置和缓存属性。我遇到过一次性能只有预期六成的情况最后发现是二级页表里把设备内存区映射成了可缓存导致每次访问都走缓存一致性流程慢得离谱。改成不可缓存之后立刻恢复正常。6. 常见问题与排查技巧实录6.1 启动阶段的典型故障启动阶段的问题占了我在这个方向上调过的 bug 的一大半而且症状都很像——没输出或者输出几行就停。这里列几个我踩过的。第一个是虚拟机完全无输出。可能原因有三个层次镜像没加载到正确地址、入口地址配错、设备树里控制台节点被裁掉了。排查顺序是从外往里先用调试器读内存确认镜像真的在那儿再确认入口地址的指令是合法的最后检查设备树的/chosen节点里stdout-path指向的设备在当前分区是否可见。第二个是输出乱码。这个问题有意思通常不是串口波特率错而是虚拟机的设备树里串口时钟频率属性不对。虚拟机看到的是物理串口寄存器操作是直通的但时钟频率如果配错算出来的分频值就错波特率自然不对。解决方法是把物理设备树里的时钟相关属性原样保留不要裁剪。第三个是启动到一半跳飞。这种八成是内存越界或者二级页表映射不全。我一般的做法是在 Hypervisor 里打开页表错误日志看异常发生的地址落在哪个区间一看就知道是哪个分区的配置有问题。6.2 运行期的抖动与性能问题运行期的问题更隐蔽因为系统在跑只是表现不符合预期。最常见的是周期性抖动。某个分区的任务本该每毫秒执行一次实际间隔在 1 毫秒到 1.8 毫秒之间波动。原因通常是调度抢占另一个分区的 vCPU 在同一颗物理核上跑抢占造成了延迟。解决办法前面说过要么绑核要么缩短抢占者的时间片。第二个是偶发的长时间停顿几百毫秒级别。这种一般不是调度问题而是某个操作触发了大量页表无效化或者缓存维护操作。我在一次调试中定位到是分区在频繁映射解映射共享内存每次操作都做全局 TLB 刷累积起来就是明显的停顿。改成局部刷之后问题消失。第三个是中断丢失。表现是设备偶尔不响应重启就好。这类问题要查中断注入的槽位管理尤其是高中断频率场景下槽位满时的排队逻辑有没有漏洞。我的做法是在 Hypervisor 里加计数器统计槽位满的次数和丢弃的次数跑压力测试看这两个数字只要丢弃不为零就必须修。6.3 排查速查表把上面这些整理成表出问题时按顺序过一遍能省不少时间现象优先排查项常用手段虚拟机无任何输出镜像地址、入口地址、控制台设备可见性调试器读内存、反汇编入口输出乱码串口时钟属性、波特率配置对比物理与虚拟设备树差异启动中途异常二级页表映射范围、内存区间重叠打开页表错误日志看故障地址运行期周期抖动vCPU 抢占、时间片长度统计调度延迟分布、调整绑核偶发长停顿TLB 全局刷新、缓存维护操作改为局部刷新、减少映射变更设备偶尔无响应中断槽位耗尽、中断号冲突加计数器统计丢弃次数性能低于预期内存属性配置、缓存策略检查页表属性位、对比原生性能最后再分享一个我觉得最值钱的习惯给 Hypervisor 加一个轻量的跟踪缓冲区把每次上下文切换、每次中断注入、每次页表修改都打上时间戳记进去出问题时把缓冲区 dump 出来。这个机制占用的资源极少但它能让你从“猜”变成“看”。我在一个偶发的调度异常上就是靠它定位的——跟踪记录显示每次异常前都有一笔来自某个特定地址的页表修改顺着这个地址找到了一个第三方驱动的越界写。这套东西搭起来的前期投入不小设备树的坑、调度的坑、中断的坑每一个都得花时间趟。但趟完之后你会发现同一颗芯片能干的事多了一倍而且各个系统之间互不干扰现场的故障半径从整机缩小到单个分区。我个人在实际操作中的体会是前期在设备树校验和跟踪机制上多花的两三天会在后面的调试里十倍地还回来别省这个工夫。