最近组里要做Type-1虚拟化方案调研我把xvisor的源码完整翻了一遍。老实说市面上讲Linux KVM的多讲开源Type-1 hypervisor的少能把Xvisor这套源码讲明白的更少。这大概是很多人卡在虚拟化源码分析门口的原因上手就去看KVM结果被Linux内核那几万行基础设施先绕晕了。xvisor不一样它是一个专门做虚拟化监视器的项目代码量小、边界清楚、从零启动就能直接跑在QEMU上非常适合用来搞懂“虚拟机监视器到底在干什么”这件事。这篇文章我尽量按源码分析的路子走把xvisor的定位、启动流程、CPU虚拟化、内存虚拟化、设备模拟这些核心模块拆开讲最后附上我实际编译和运行它的完整过程。适合四类人看刚接触虚拟化的学生、准备做嵌入式虚拟化选型的工程师、想搞清楚Type-1 hypervisor和KVM区别的开发以及所有对着源码无从下手的人。1. 先说清楚xvisor是什么1.1 Type-1 hypervisor和Linux里的KVM不是一回事虚拟化方案分成两类Type-1和Type-2。Type-2的代表就是桌面上的VMware Workstation、VirtualBox以及Linux内核里以模块形式存在的KVM。KVM虽然需要硬件虚拟化扩展来跑但严格讲它是“Linux内核的一部分”得靠一个完整的操作系统来主持大局。xvisor不是寄生在别人身上的它自己就是一个独立运行的轻量级虚拟机监视器直接跑在硬件上。启动顺序是硬件固件比如U-Boot加载xvisor然后xvisor分配资源、创建虚拟机和vCPU再把客户机请进来。客户机永远不知道底层其实还有一层监视器。这个定位有一点非常关键xvisor自身不提供文件系统、不提供网络协议栈、不提供用户态服务它只提供“把CPU、内存、外设安全地分给多个客户机”这一件事。源代码里你找不到进程、文件描述符这些概念只有guest、vcpu、vdev这些虚拟化领域的原生活汇这对源码分析来说是极大的减负。1.2 为什么拿xvisor当源码分析对象市面上开源的Type-1又不是只有它OpenAMP的remoteproc那套不算跟它同类的是像sel4这样的微内核方案。但xvisor有几个特点很合我口味。第一它活跃度高、还在演进不是个死项目。第二它对ARM32/ARM64和RISC-V支持都非常直接这些都是嵌入式虚拟化场景的主力架构。第三它完整实现了虚拟机的生命周期管理从设备树解析、内存分区到vCPU调度的代码都在src目录下结构性很强适合当教材。更重要的一点是xvisor可以方便地在QEMU里跑起来。裸机上调试hypervisor是比较痛苦的但QEMU模拟一个ARM机器几分钟就能见到串口输出。这就意味着你不光能读代码还能动手验证每个理解是否正确。2. xvisor源码结构和启动流程解析2.1 代码目录怎么读xvisor的源码目录不算大但初学者拿到手还是容易懵。我建议按这个顺序读src/arch/架构相关代码x86、ARM、RISC-V的实现都在这边。看完整个虚拟化的共性再回来看这个目录会舒服得多。src/core/与具体架构无关的核心逻辑比如vmm_vcpu.c、vmm_sched.c、vmm_mem.c这些。这里的文件才是最值得精读的。src/vmm_devemu/虚拟设备模拟器框架客户机访问外设地址时会走到这片代码。lib/xvisor自己带的一套轻量级C库实现用来替代标准libc。读的时候不要用看应用代码的习惯去追调用栈而是要找“状态机”。hypervisor本质上就是一堆状态机客户机处于运行态、被中断钉住、等待I/O完成、被调度出去。2.2 入口与早期初始化xvisor的入口不复杂但它跟普通嵌入式固件很像第一条指令由链接脚本指定通常落在arch目录下的汇编入口文件里。汇编代码做的是一件事把底层环境清干净然后跳转到C语言的vmm_main函数。vmm_main整个启动初始化顺序是分层搭积木。最先建立的是基础内存管理因为后面的一切数据结构都需要分配内存。接着是调度器初始化再然后通过设备树找到平台配置。等基础ready后系统创建第一个虚拟机也就是用来干活的客户机并为它创建vCPU。所有初始化完成后才进入调度主循环。这个顺序理解透了对后续读源码很有帮助hypervisor自己就是个小操作系统一切都从内存和调度开始。2.3 设备树到底扮演什么角色xvisor和现代ARM固件一样重度依赖设备树DTB。它启动时解析DTB从中获取两个信息一个是硬件平台本身有哪些外设另一个是客户机期望的外设配置。xvisor自己不算“完整的OS”没有驱动模型那一堆它对设备树的使用是精简的找到目标设备的reg地址、中断号、时钟这些信息然后建立内存映射关系。读这块代码时最容易犯的错是把设备树当成配置数据库去到处翻。其实它在xvisor里更像“贴身地图”告诉我哪些地址范围要留给自己、哪些地址范围可以开放给客户机。一个极典型的场景虚拟串口设备。客户机以为自己在访问UART寄存器实际上地址被xvisor截获然后转发给底层物理UART或者模拟后端。3. CPU虚拟化vCPU、调度与异常捕获3.1 vCPU是虚拟机的心脏在xvisor里一个虚拟机叫guest一个guest里面可以有很多个vCPU。vCPU不是一个简单的线程结构它是一个完整的处理器上下文对象保存着寄存器组、系统寄存器、异常状态、以及调度器需要的状态。在ARM架构下xvisor运行在比客户机更高的特权级。客户机的应用程序和内核跑在较低的异常级而xvisor自己拥有更高异常级的控制权。当客户机想执行特权操作、配置MMU或者访问敏感寄存器时会触发异常陷入xvisor这时候保存现场、切换上下文然后在安全侧模拟操作再切回客户机。类似场景就像办公室里每个工位配了保安表面上的员工在座位上干活真正遇到门禁、钥匙这些事务的时候保安出面处理员工只知道自己正常用了门禁不知道内部发生了什么。3.2 进入和退出Guest的关键路径xvisor切到客户机的过程本质是改变异常级别并且恢复客户机的寄存器。而客户机主动退出比如通过执行一条特殊指令或者被动退出比如发生了物理中断则会把控制权还给xvisor的异常向量表。这个异常向量表是所有虚拟化机制的中枢任何从客户机“逃逸”到hypervisor的事件都从这里进来。vmm_vcpu.c里把进来的异常分成几个大类数据异常客户机访问了不该访问的内存、外部中断物理设备信号到来、同步异常客户机主动发了特殊指令。每类异常走不同的handler但入口统一这套设计在ARM和RISC-V的代码里都能看到。我实际读这段时最大的感受是虚拟化没有魔法一切“隔离”都是由异常触发和上下文切换拼出来的。只是现代CPU把这些上下文切换的成本尽量降到最低而xvisor暴露出来的恰恰是这个最本质的动作。3.3 调度器没有进程概念的“进程调度”xvisor内部实现了一个极轻量的调度器所有vCPU以及其他系统管理线程都在这上面跑。它的调度粒度是“任务”每个任务有自己的上下文、栈、优先级。我原以为这种轻量级hypervisor会采用极其简单的round-robin但读源码后发现它还是保留了一点优先级和事件驱动机制。当一个vCPU等待虚拟设备的I/O结果时它会被挂起调度器可以切到另一个可运行的vCPU。当一个物理中断到来时调度器会唤醒对应的虚拟中断处理器。关键理解点在于hypervisor的调度器不需要像Linux那样处理复杂的时间片、组调度、HZ概念因为每个vCPU背后几乎总是对应一整块“客户机时间”调度的粒度本身就很粗。4. 内存隔离的关键两阶段地址转换与设备模拟4.1 从客户机虚拟地址到物理地址发生了什么xvisor处理内存的思路跟树莓派用户自己“手动管理”没有本质区别只是它用手写代码替代操作系统。每个客户机都有一个受控的物理地址空间视图。客户机以为自己访问的是0x40000000这样的“物理地址”但真正的物理内存可能被xvisor映射到了另一个位置。为了做到这一切现代ARM处理器提供两阶段转换客户机里的虚拟地址先经过它的页表翻译成客户机物理地址这个客户机物理地址再经过hypervisor控制的第二阶段页表翻译成真实物理地址。xvisor维护的就是第二个阶段的页表。客户机可以对它的页表做任何事但永远影响不到第二阶段页表。这一层隔离会让第一次读源码的人觉得有点绕但它恰恰是整个系统安全的基础。xvisor源码里围绕每个guest都维护了一块“物理内存布局”记录了哪些区域是给客户机的代码段、哪些区域是给它当设备空间用的。这个布局不是动态算出花来的而是由启动时的配置决定。好处是确定性强、好排错。4.2 设备模拟的核心vdev客户机可不会只跑纯计算任务它要打印、要收发网络包、要处理中断。这就轮到vdev虚拟设备模块上场。xvisor的套路是把客户机物理地址空间里的一段区域划给虚拟设备然后这段区域的实际读写操作会被捕获。当一个客户机向这个地址发起写操作时MMU访问权限会触发数据异常异常处理流程区分出“这是虚拟设备的MMIO地址”后调用对应vdev实例的处理函数。我建议读这一部分时把自己放到实现者的位置去思考一个问题如果我要模拟一个串口客户机的驱动会读写哪些寄存器读写这些寄存器时我是直接转发给物理串口还是塞进一个内存缓冲里等模拟后端慢慢处理xvisor的代码里这些思路都清晰可见它把“设备模型”和“具体模拟后端”解耦得很干净。4.3 中断模拟虚拟中断控制器外设模拟只做了一半另一半是中断。客户机需要通过中断控制器知道“新数据到了”。xvisor为每个guest创建一个虚拟中断控制器实例当主机侧物理中断到来时xvisor根据路由规则决定把虚拟中断注入到哪个vCPU。中断注入的代码在源码里是一段很精妙的状态管理。中断不是“设置一个标志位”就完了而是要配合vCPU的状态如果vCPU正在运行需要先暂停它然后注入中断再恢复运行如果vCPU正处于等待状态那注入操作要跟唤醒操作合并。这块漏看容易造成对虚拟化性能的误判。注入中断的开销虽然不算大但在高频网络场景下累积起来很明显这也是为什么很多高性能方案会考虑中断直通把设备直接绑给客户机绕过hypervisor的中介。理解了xvisor的虚拟中断路径也就理解了为什么会有直通这种优化方案出现。5. 从源码到跑起来我用QEMU完整跑了一遍5.1 需要准备的工具链我是在Linux环境下做的纯命令行工具。交叉工具链我用的是arm-linux-gnueabi装好后主要用到的是它的gcc和ld。QEMU用来模拟完整的ARM机器我用的qemu-system-arm。另一个必须的东西是设备树编译工具dtc有些版本在构造测试镜像时需要它。5.2 编译xvisor的基本操作xvisor的构建系统跟Linux内核一个路子都是kconfigMakefile。先去官网仓库把代码clone下来然后进到根目录。确定架构和目标平台我是这样配置的make ARCHarm vexpress-a9_defconfig make如果嫌默认配置不够灵活也可以用menuconfig去手动开关。xvisor的编译时间很短交叉编译情况下在普通笔记本上只要一两分钟比动辄半小时的内核编译友好得多。编译产物里最核心的是两个文件xvisor.bin这是裸机二进制可以直接被引导加载xvisor这是带符号表的ELF文件调试用的别删。5.3 在QEMU中启动xvisor我用QEMU模拟vexpress-a9开发板来跑命令非常简单qemu-system-arm -M vexpress-a9 -m 512M \ -kernel /path/to/xvisor.bin \ -nographic指定-machine为vexpress-a9分配512MB内存用-nographic把串口输出引到当前终端。第一次看到串口输出的时候是很激动的因为一行又一行初始化日志说明xvisor完成了启动、设备树解析和虚拟机创建整个过程没有任何宿主操作系统参与。如果需要让虚拟机里真正运行客户机代码则需要额外通过启动参数挂载客户机的镜像。调试阶段我更喜欢先让xvisor单点启动确认监控器本身没问题再接客户机。5.4 调试技巧日志与串口xvisor本身有完整的日志系统就是printk那套的极简版。我调试时开了VERBOSE级别的日志可以看到每次异常触发是哪个地址、哪个vCPU。这个信息对排查客户机崩溃太有用了。还有一个很实用的技巧是把串口重定向到telnet端口这样可以另开终端随时连进去敲底层命令而不是只能看一行行输出。对源码分析来说这个“能交互”和“只能眼巴巴看日志”差距非常大。6. 源码阅读中的常见问题与排查心得6.1 编译失败工具链版本和配置不对最容易遇到的第一类问题就出在交叉工具链上。xvisor对警告处理很严格老工具链或者太新的工具链都可能出现编译中断。我的经验是先确认用arm-linux-gnueabi这类通用目标而不是ARM裸机工具链然后如果报错集中在汇编语法上基本就是工具链匹配问题。第二个是配置选错平台。xvisor支持很多开发板选错defconfig虽然能编译但跑起来会有莫名其妙的行为。起步阶段务必选一个跟QEMU机器一致的配置。6.2 启动后完全没有输出这个坑很经典。QEMU起来后屏幕上什么都没有问题九成不在hypervisor而在于串口先于初始化就不可用了。xvisor的早期日志输出依赖硬件串口基地址如果地址配置跟QEMU模拟的机器不匹配所有输出都丢在虚空里。排查方法很简单先确认QEMU机器的串口地址再对比xvisor设备树或配置文件里的对应地址。在vexpress-a9上用的地址跟树莓派完全不同很多人默认按Bombing address搞结果当然一片寂静。6.3 客户机启动后反复重启启动日志正常、虚拟机也创建了但客户机一跑就跳回启动流程。这个问题我排查时发现根因往往在中断路由客户机的虚拟中断没有被正确配置客户机以为自己收到了外部中断结果处理完返回就乱了。这种问题最能体现源码阅读的回报。如果你已经看过vmm_vcpu的异常处理流程你会懂得从“虚拟中断控制器配置”和“vCPU进入前的中断屏蔽状态”两个角度去查而不是一头扎进去改迷茫的客户机代码。6.4 我踩过的另一个隐蔽坑内存布局乌龙自从有一次客户机老在地址0附近崩溃我以为是客户机代码问题结果发现是xvisor给客户机分配的物理内存起始地址跟我预期的不一致。客户机里完全没有内存管理概念根本不知道自己的物理地址跟宿主机看到的物理地址差了一大截。后来我养成了一个习惯凡是客户机地址异常先回头核对第二级页表映射关系。只要这块区域映射对了剩下的基本上都是中断和寄存器模拟范围的代码逻辑问题。最后的重点读xvisor源码到底能收获什么读完整套xvisor的核心代码后再回头看虚拟化这个词你会发现它其实是个不加魔法的妥协艺术。CPU可以靠硬件扩展陷入虚拟化事件内存可以靠两阶段页表隔离外设可以靠异常机制模拟但这一切都要通过异常路径这个唯一的瓶颈串联起来。xvisor的价值正在于它把这些机制精简到了几乎不可再砍的程度每一行代码都有落点和原因这是读书时看不来的功底。对我来说最大的收获不是学会了某个API而是建立了一种关于虚拟化系统的整体直觉任何虚拟机监视器无论商业的还是开源的最终都要回答四个问题客户机从哪里进来客户机在哪里停下客户机看到的地址是谁的客户机以外的事件由谁处理。把这四个问题在xvisor源码里对号入座之后再去看KVM、看商业虚拟化方案都不再有云里雾里的感觉。如果你也打算深入研究虚拟化我给的一条最实在的建议是先别碰那些大而全的框架就把xvisor这一套源码从头到尾跑通一遍再挑其中一百行代码逐行做注释。当你能够指着源码说出“这条异常路径在什么场景下被触发、随后系统状态会发生什么变化”的时候虚拟化的门槛就已经迈过去了。
