完整的虚拟化系统通常不只包含Hypervisor。为支撑客户OS的启动与运行，并提供CPU、内存、中断、设备及生命周期管理等虚拟化功能，通常还需要Host OS、管理域、用户态管理程序、设备后端、驱动以及各种系统服务共同参与。这些软件层级与组件共同构成完整的虚拟化栈（Virtualization Stack）。

虚拟化栈越长，意味着参与运行的软件层级越多、组件越多，客户OS关键操作需要经过的处理环节也越多。ZVM所强调的虚拟化栈最小化，核心并不是简单追求"代码量少"，而是：在满足嵌入式虚拟化功能需求的前提下，尽可能减少虚拟化运行所依赖的软件层级和独立组件。其核心可以概括为三个"少"：

• ● 少层级：减少Host OS、管理域等中间软件层；
• ● 少组件：减少独立用户态VMM、设备模型和外围管理组件；
• ● 少切换：减少跨域、用户态与内核态以及不同软件层之间的切换。

通过上述精简，ZVM减少虚拟化运行中的中间层级、独立组件和跨层切换，最终形成更短、更直接的虚拟化执行路径。

不同虚拟化系统除了Hypervisor本身，在虚拟化栈组成、外围依赖及栈特征上存在明显差异。

表1：主流虚拟化方案的虚拟化栈对比

KVM采用内核态与用户态协同机制，部分I/O和VM事件需要退出到用户态处理Xen则通过Domain 0承担虚拟机管理、后端驱动等重要职责；Jailhouse运行时较为轻量，但采用静态分区方式，并由Linux负责加载、配置和资源划分，系统首先启动Linux，再启用Jailhouse并从Root Cell中划分资源。ZVM的"最小虚拟化栈"并不等同于"Hypervisor更小"，其更加关注：在满足产品级嵌入式虚拟化需求的前提下，完成整个虚拟化系统需要多少软件层级和组件共同参与。

ZVM采用RTOS原生虚拟化架构，将实时内核与虚拟化功能一体化设计。CPU调度、内存管理、中断管理、设备管理等RTOS已经具备的基础能力，被直接用于支撑vCPU、客户OS内存、虚拟中断和虚拟设备管理，不再额外叠加一套独立的虚拟化基础设施。同时，客户OS生命周期管理、VirtIO后端等虚拟化服务直接内置于ZVM，无需部署在独立Host Linux、Domain 0或外部用户态VMM中。ZVM的虚拟化栈可概括为：

VirtIO设备访问可以直观体现虚拟化栈在I/O路径上的差异。在依赖独立管理域或者独立设备后端的架构中，客户OS的一次I/O请求通常需要经过多个软件组件后才能到达物理设备。

图1：虚拟化最小栈示例——I/O路径

ZVM将VirtIO后端直接实现于自身内核，无需额外的特权客户OS承担I/O后端功能。I/O请求可在ZVM内部完成虚拟设备处理并访问物理设备。在保留VirtIO功能的前提下，"最小化"在此处体现为减少承载VirtIO功能的中间组件和软件层级，进而减少跨Domain通信、额外调度和上下文切换，缩短I/O处理路径，有利于降低运行开销和时延抖动。

客户OS创建、资源分配、启动和停止同样可以体现虚拟化栈差异。在通用虚拟化方案中，生命周期管理通常由独立管理工具、用户态Toolstack或管理域完成，再通过Hypervisor提供的控制接口完成客户OS创建和资源配置。

图2：虚拟化最小栈示例——客户OS生命周期管理

ZVM将客户OS创建、加载、启动、暂停和停止等生命周期管理能力直接内置，不依赖独立Domain 0完成控制。ZVM无需为客户OS管理额外运行完整的通用操作系统或庞大的外围管理环境。由此减少管理组件和调用切换环节，降低软件耦合与运行资源占用。

虚拟化栈最小化最终并不是为了追求架构形式上的"简单"，而是直接服务于嵌入式系统的资源效率和实时确定性。

需要强调的是：代码规模下降是虚拟化栈最小化的结果之一。衡量系统轻量化程度，更应关注一项虚拟化功能需要多少软件组件参与，以及关键操作需要跨越多少软件层级。

ZVM的轻量化并不是简单地去追求"做一个更小的Hypervisor"，其核心思想是：通过RTOS原生虚拟化，将CPU、内存、中断、设备和客户OS管理能力收拢到一套内核中，减少Host OS、管理域、独立用户态VMM、独立设备后端及外围管理组件，形成最小虚拟化栈。总体来看，ZVM的轻量化，最终可以归结为三个方面：少组件、短路径、低开销，这也是ZVM面向嵌入式实时系统进行虚拟化架构设计的核心出发点。