在嵌入式与实时系统领域，Hypervisor 的架构层级与代码规模直接决定了系统的实时性、可控性以及工程落地成本。

本文围绕两个常被关注的问题展开说明：
（1） ZVM 的代码规模到底有多大？
（2）ZVM 在架构上是否属于Type 1 Hypervisor？

通过对ZVM架构组成、代码体量、性能数据及其与主流虚拟化方案的对比分析，本文给出明确结论：ZVM 是一款面向嵌入式与实时场景的轻量级Type 1 Hypervisor。

在实际测试中，ZVM同时运行RTOS与Debian Linux两款客户操作系统，在多个测试集上表现稳定（相对于裸金属）：

如此低的虚拟化开销表明，ZVM 并非依赖宿主操作系统提供资源管理能力，而是直接介入并掌控底层硬件资源。这一性能指标不可能由 Type 2 Hypervisor 达成，进一步从侧面印证了 ZVM 的 Type 1 架构特征。

图1：性能指标对比

在早期技术交流中，ZVM 曾被描述为 “Type 1.5 Hypervisor”。这一说法的出发点，并非对其架构层级的重新定义，而是用于解释 ZVM 在工程实现方式上的灵活性。从架构本质上看，ZVM 始终属于 Type 1 Hypervisor。

之所以在部分场合出现 “Type 1.5” 的表述，是因为 ZVM 在 Type 1 架构基础之上，充分利用了 Zephyr RTOS 的模块化设计能力，在工程实现层面实现了高度灵活的组件复用方式。例如，在某些使用形态下，ZVM 可以复用 Zephyr 已有的驱动与子系统，以降低系统集成成本并提升开发效率。这种工程实践在嵌入式虚拟化领域并不罕见，QNX Hypervisor 等成熟产品亦采用了类似思路。QNX Hypervisor官方文档给了个示意图，指出它的本质基础是Type 1，但具备跨Type 1（嵌入式）到Type 2（桌面）的虚拟化能力。

图4：QNX 官方对跨形态虚拟化能力的示意

ZVM 的工程侧重点体现为两种形态：

1. 面向嵌入式与实时场景的 ZVM 发行版：实时内核、子系统与 BSP 均经过深度裁剪，重点关注确定性、可控性与功能安全需求。这一形态下的 ZVM 是典型的嵌入式 Type 1 Hypervisor。
2. 用于功能验证与开源协作的 ZVM 开源版本：以完整 Zephyr RTOS 为基础运行于 QEMU 等环境中，未对 Zephyr 宿主系统进行裁剪，以便于功能验证、桌面环境调试以及后续向 Zephyr 主线合并，这属于典型的Type 2 Hypervisor。

综上，ZVM 在架构本质上始终为 Type 1 Hypervisor，所谓 “Type 1.5” 的说法，仅用于描述其在工程实现与使用方式上的灵活性，而非对其架构层级的重新分类。