表1：RTOS实时内核机制与虚拟化功能的一体化对应关系

• • 统一资源控制：将RTOS原有CPU、内存、设备等资源管理机制直接扩展到虚拟化场景，实现物理资源与虚拟资源的一体化控制；
• • 统一实时调度：复用RTOS实时调度机制统一管理RTOS任务和Guest vCPU，通过1V1静态绑核隔离CPU资源，并采用O(1)复杂度调度实现确定性任务切换，减少多套调度体系之间的协同开销；
• • 统一中断与时间路径：将物理中断、虚拟中断和定时机制纳入同一实时控制路径，缩短事件响应链路并降低时间不确定性。

表2：KVM、Xen、Jailhouse与ZVM的内核与虚拟化的组织方式对比

• 1） KVM的设计已经具有较高的内核集成度，其API通过/dev/kvm及一系列ioctl由用户态创建Guest、vCPU和设备，KVM_RUN负责进入Guest执行；对于需要用户态设备模型处理的Guest Exit，执行路径还需要返回用户空间（QEMU）。
• 2） Xen与Dom0等服务域相互独立，并共同承担系统管理职责。Xen的xl工具则负责Guest创建、暂停、关闭等操作；Dom0默认获得设备并负责Guest I/O复用。这种分层具有清晰的系统边界，但部分完整功能需要Hypervisor与Dom0之间跨层协作。
• 3） Jailhouse只虚拟化无法直接硬件分区的必要资源，其他资源都采用硬件划分的方式。其中，Root Cell首先启动并加载、配置Jailhouse，之后各Cell使用静态划分的资源运行。在单纯的静态CPU和设备直通场景中，Jailhouse的运行路径本身较短。
• 4） ZVM并不是通过取消调度、减少虚拟化功能来获得实时性，而是希望在保留RTOS调度、虚拟中断、虚拟设备、VirtIO以及系统服务能力的同时，将这些能力直接组织到实时内核中。其技术重点是：既要短路径，也要完整的实时虚拟化能力。

• 1） KVM中的Host管理vCPU调度而KVM通过KVM_RUN运行Guest。Guest同时受到Host调度体系以及KVM的共同控制。对于需要用户空间处理的Guest Exit，还需返回用户态VMM中，然后再次进入Host。即使采用VHE减少EL1与EL2之间的特权级切换，其并不改变其"Linux Host + KVM + 用户态虚拟机"控制的基本组织形式，Host仍然是一套面向通用操作系统设计的调度与服务体系。
• 2） Xen负责vCPU调度而Dom0拥有自己的操作系统调度体系。对于单纯的vCPU调度，Xen可以直接在Hypervisor内完成；但当事件涉及Dom0中的设备Backend或者系统服务时，就会形成"Dom0服务处理→Xen事件通知/调度→Guest vCPU运行"的跨Domain协同关系。Xen的典型Backend机制使用事件通道和共享Ring连接前后端，也就是说，系统中同时存在Hypervisor调度域和Dom0操作系统调度域。
• 3） Jailhouse干脆不做vCPU调度。一个Cell获得CPU之后长期独占该CPU运行，因此不存在"Hypervisor下一步应该调度哪个Guest"的问题。这使Jailhouse在静态实时分区场景中具有天然优势，但同时意味着它并不提供一套用于统一管理"RTOS任务 + 多Guest vCPU"的实时调度体系。
• 4） ZVM采用的是另一种方式。RTOS本身已经拥有成熟的CPU管理、优先级及实时线程控制机制。ZVM不再额外建立一套独立的Hypervisor调度体系，而是直接复用RTOS内机制。其逻辑关系可以简化为："实时事件 → ZVM实时内核 → 统一中断/调度机制 → 本地实时任务或Guest vCPU → Guest运行"。这里减少的是"RTOS内核 → 独立Hypervisor → Host/管理OS → 再回到Hypervisor"这一类软件控制权转交。对实时系统来说，需要分析最坏情况下究竟经过多少调度点、多少执行环境及不确定的流程。因此，本地实时线程、Guest和事件响应可以置于一套实时控制体系中分析。

图1：实时事件到Guest运行的典型控制路径对比：ZVM强调统一实时控制与少切换

• 1） KVM的用户态设备模型处理的路径表现为："Guest→KVM→用户态VMM→Host Linux I/O/驱动 →KVM→Guest"。例如，虚拟设备产生设备异常时，KVM_RUN返回用户空间后可以由用户态完成相应Guest exit处理，再重新进入Guest。当然，KVM可以通过vhost、设备直通以及VHE等机制明显缩短特定I/O路径。这里比较的是需用户态设备服务参与的典型完整虚拟设备路径，不是所有KVM I/O都必须经过QEMU。
• 2） Xen的典型前后端设备模型中路径可以表示为："Guest Frontend → Xen跨域机制 → Dom0 Backend → Dom0设备驱动 → Xen事件通知 → Guest"。Dom0通常获得设备并承担Guest I/O复用，其前后端接口通过共享Ring和Event Channel完成请求与通知。所以一次设备请求不仅涉及Guest和Hypervisor，还可能涉及另一个具有独立调度与状态管理体系的Domain。
• 3） Jailhouse直接将设备静态分配给某个Cell："Cell → 物理设备"。这正是Jailhouse静态分区的优势，Jailhouse官方设计明确强调不进行通用设备仿真，但这里存在一个重要前提："设备必须能够静态划分"。当系统进一步需要多个Guest共享网络、GPU、存储等资源，需要VirtIO、SR-IOV管理或其他虚拟设备服务时，就必须增加额外的软件机制。也就是说，Jailhouse主要通过"尽可能少做虚拟化"获得短路径。
• 4） ZVM同时获得两方面能力："短路径+虚拟设备服务"。其典型路径可以收敛为："Guest Frontend → ZVM内置虚拟设备服务 → ZVM I/O/驱动 → 物理设备"。设备完成后："物理中断 → ZVM中断机制 → 虚拟中断 → Guest"。ZVM的虚拟化栈最小化设计已经明确提出，不依赖独立Host/管理域和QEMU等用户态VMM，而将设备虚拟化、I/O和系统服务直接在ZVM内部实现。

这里体现的正是一体化架构与另外两项架构创新之间的配合：

• • 实时内核与虚拟化功能一体化，减少内核与虚拟化控制之间的切换；
• • 虚拟化栈最小化，减少Host、用户态VMM等软件层级；
• • 无管理域服务下沉，减少Guest、Hypervisor与管理OS之间的跨域服务转交。

最终目的都是让关键实时路径更加直接和可控。

图2：Guest虚拟I/O典型服务路径对比：ZVM将虚拟设备服务与I/O能力组织在统一RTOS底座内

ARM架构上VHE硬件特性进一步为这种一体化提供了硬件基础。VHE模式下Host 可以运行于EL2，而nVHE模式下Host通常位于EL1。ZVM提出了HyperVHE，使"RTOS直接运行在虚拟化控制特权级，实时内核本身执行虚拟化控制"，控制管理统一在EL2实时内核内部直接完成，同时支持ARMv8.0和ARMv8.1+的所有硬件。