ZVM技术解读·内核篇①｜HyperVHE超级虚拟化扩展
01 什么是超级VHE
在虚拟化系统中，Hypervisor为了保证自身的精简性，通常选择将客户OS生命周期管理、I/O后端处理等功能托管给一个服务OS执行，如KVM的Host Linux、QNX Hypervisor的QNX OS和Xen的Dom0等。
在ARMv8.0-A架构中，如图1（a）所示，服务OS通常运行在EL1，Hypervisor运行在EL2，两者之间存在一个特权级差距。因此服务OS与Hypervisor交互时需要频繁跨EL，从而带来了不可避免的特权级切换开销。这类模式在KVM中被称之为nVHE，在其他Hypervisor中虽然不一定采用“nVHE”这一名称，但具有同样的EL分层结构。为消除这类跨EL开销，ARMv8.1-A引入了VHE（Virtualization Host Extensions，虚拟化主机扩展）这一硬件特性。如图1（b），VHE允许原本面向EL1设计的服务OS直接运行在EL2，服务OS和Hypervisor之间的跨EL交互转化为EL2的内部函数调用。
图1. nVHE、VHE、HyperVHE对比
但VHE仅适用于ARMv8.1-A及以上架构，而大量已部署的国产嵌入式处理器（如飞腾E2000、D2000等）仍是ARMv8.0-A架构，无法提供VHE的硬件特性支持。这直接导致依赖VHE的高性能虚拟化方案难以在上述平台上部署，严重制约了系统的适用范围与生态扩展能力。相较之下，nVHE模式虽然能够运行在ARMv8.0-A架构之上，但其在特权级切换、中断处理和上下文管理方面引入了显著的软件开销，对实时性和系统简洁性产生不利影响。
针对这一兼容性与性能之间的矛盾，ZVM设计并实现了一种增强型虚拟化模式——超级VHE（HyperVHE）。如图1（c）所示，ZVM通过“内核升级”+“虚拟化重构”实现了一套统一的虚拟化实现框架，可覆盖ARMv8-A全系列架构。在性能表现上，HyperVHE在不依赖硬件VHE的前提下，整体效率略优于原生VHE，同时显著优于传统nVHE实现。
02 主流虚拟化方案的架构对比
虽然ARMv8.1-A提供了VHE硬件能力，并不意味着所有Hypervisor部署在ARMv8.1-A架构的处理器上时都会采用VHE。
表1：各Hypervisor对nVHE、VHE的支持情况
| Hypervisor | 是否支持nVHE或者类似分层的架构 | 是否支持VHE |
|---|---|---|
| Xen | 是 | 否 |
| Jailhouse | 是 | 否 |
| KVM | 是 | 是 |
| QNX Hypervisor | 是 | 是 |
| ZVM | 否 | 是 |
如表1所示，各类Hypervisor对VHE的支持情况存在差异：
- 1） 即使在ARMv8.1-A上Xen和Jailhouse也并不支持VHE，导致了Xen和Jailhouse中不可避免的跨EL开销。以Xen为例，他的虚拟化层和服务OS之间是各自独立的，因此从最初的架构与设计上就无法使用VHE。
- 2） KVM和QNX Hypervisor虽然同时支持nVHE和VHE，可以根据硬件能力灵活选择。但是部署在ARM8.0-A上时，也依旧只能选择nVHE模式。不可避免地引入大量的跨EL开销。
- 3） 早期ZVM则属于另一种情况。ZVM在设计之初就只考虑了ARMv8.1-A，采用RTOS原生虚拟化架构，依赖VHE将实时内核与虚拟化模块统一运行在EL2。换句话说ZVM由于没有nVHE的支持无法部署在ARM8.0-A上。
03 超级VHE：内核升级
超级VHE的第一项核心改造是内核升级。ZVM将承担服务操作系统角色的RTOS实时内核从EL1提升到EL2，使其与虚拟化模块位于同一异常级别。这样，实时内核与虚拟化模块之间的控制交互可以收敛为EL2内部调用，不再依赖nVHE中的EL1↔EL2陷入与返回。
要让原本面向EL1设计的实时内核稳定运行在EL2，仅改变启动入口并不够。如图2所示，ZVM重新设计内核启动路径，建立EL2所需的系统状态、内存管理和异常路由，并将关键初始化过程迁移到EL2环境。
图2. 内核升级后的服务OS与虚拟化模块
- • EL2启动路径：内核启动阶段直接建立EL2运行所需的关键寄存器状态与异常返回环境，摆脱对VHE硬件初始化流程的依赖。
- • EL2内存管理：原有内存管理以EL1访问模型为前提。升级后，需要在EL2下重新建立页表与内存访问环境，使实时内核能够在新的异常级别中继续完成内存管理与资源隔离。
- • EL2异常与中断路由：异常处理路径同步迁移到EL2，使来自系统和外设的事件能够在共享EL2环境中完成处理，并为后续Guest陷阱和虚拟IRQ传递提供统一入口。
04 超级VHE：虚拟化重构
内核升级解决了“实时内核在哪里运行”的问题，但客户OS的进入、退出、中断和异常处理等虚拟化关键路径仍需要适配新的EL2运行环境。如图3所示，ZVM进一步对原有依赖VHE语义的虚拟化机制进行重构，使其能够与升级后的EL2实时内核协同工作，主要包括以下三个方面。
图3. 虚拟化重构
- • 客户OS上下文切换。在客户OS进入或退出时，ZVM在EL2保存和恢复关键运行状态，保证切换前后上下文连续一致。
- • 客户OS异常处理。在EL2统一处理客户OS运行过程中产生的Trap和异常，识别类型后并将其转发至相应的异常处理路径。通过EL2内部函数调用分发给相应的设备驱动程序，或在EL2本地处理。
- • 虚拟中断注入。外部中断触发后，直接在EL2层完成异常分发，并根据映射关系将中断精准投递至目标客户OS，避免在EL1与EL2之间进行多余跳转，提高中断处理效率与系统确定性。
05 总结
通过实时内核EL2特权级改造与虚拟化机制重构，ZVM的HyperVHE模式有效规避了传统nVHE在性能与实时性方面的固有缺陷，具体体现在以下几个方面：一是突破硬件架构限制，使ARMv8.0等不支持VHE的处理器同样具备高效虚拟化能力；二是消除跨特权级切换带来的额外开销，将关键路径延迟降至最低，满足实时系统需求；三是实现多客户操作系统之间的高效调度与强隔离，适配中低端嵌入式平台资源受限的应用场景。