ZVM官方网站

01 概述

ZVM 高安全隔离机制的核心目标，是严格阻止故障在不同客户 OS 之间“传播”，为每一个客户 OS 建立一个独立、受保护的“免疫空间”。在这一空间内，客户 OS 的异常、错误配置或驱动缺陷，都不会影响其他 OS 的正常运行。为实现这种强隔离性，ZVM 从两个方面构建防线：基础硬件隔离与关键设备隔离。

图1. 客户OS间故障隔离

如图1所示，多个客户 OS（包括非实时域和实时域）同时运行在同一套硬件平台之上，但在 ZVM 的管理下，每个客户 OS 都被划分到一个明确的“独立空间”中。图中用箭头明确标出了“故障传播”被阻断的位置，强调即便客户 OS1 发生异常，也无法跨越 ZVM 这一隔离层影响客户 OS2 或客户 OS3。这一整体结构直观展示了 ZVM 在系统架构层面对故障隔离的基本定位。

02 基础硬件隔离

基础硬件隔离是ZVM构建高安全隔离的第一道防线，主要针对 CPU、内存和定时器等所有客户 OS 都必须共享的基础资源。ZVM 通过 vCPU 机制，为每个客户 OS 提供独立的执行上下文，即便多个客户OS运行在同一个物理CPU（pCPU）上，它们的上下文状态也不会相互污染。

这一点在图2中得到了具体体现。图中展示了客户 OS1 与客户 OS2 同时运行在同一个 pCPU 上的情况。每个客户 OS 都拥有各自的 vCPU（vCPU-A、vCPU-B）以及独立的 OS 上下文，ZVM 在底层负责 vCPU 与 pCPU 的调度和切换。即使两个客户 OS 共享同一物理 CPU，它们的任务 A 和任务 B 仍然运行在严格隔离的上下文中，避免了执行状态相互干扰。

图2. 客户OS vCPU上下文隔离

图3. 客户OS 内存和定时器隔离

在内存与定时器维度，ZVM 进一步利用处理器提供的 Stage-2 地址转换机制，实现硬件级隔离。客户 OS 认为自己访问的是连续的“物理内存”，但这些地址实际上是中间物理地址（GPA），最终由 ZVM 在 Stage-2 中映射到互不重叠的真实物理内存区域。如图3所示，客户 OS1 和客户 OS2 分别通过 Stage-1 和 Stage-2 两级地址转换访问各自的内存空间，同时各自维护独立的 vTimer 状态。这种设计从硬件层面确保了不同客户 OS 的内存和时间基准互不干扰，是“独立空间”成立的基础。

03 关键设备隔离的挑战

在完成基础硬件隔离之后，更大的挑战来自于关键设备的隔离。在ZVM中，GIC（中断控制器）、CRU（时钟复位控制器）和 SYSCON（系统控制寄存器）一旦被错误操作，其破坏是全局性的，可能直接影响所有客户 OS。

（1）GIC 中断控制器

以 GIC 为例，GIC 负责管理硬件和虚拟中断，保证客户 OS 能够及时响应外部设备的中断请求。如果缺乏隔离，某个客户 OS 擅自修改 GIC 配置，可能导致 CPU 响应中断信号时发生错误，甚至造成其他客户 OS 的中断信号丢失。

图4. GIC中断控制器示例

这一风险在图4中被明确展示。图中，客户 OS1 和客户 OS2 分别通过各自的 vCPU 接收 IRQ-9 和 IRQ-10。如果客户OS1错误修改了 GIC 中的中断配置，就可能影响 IRQ-10 的投递，导致客户OS2因缺少中断而崩溃。这正是关键设备必须隔离的根本原因。

（2）CRU 时钟与复位配置

CRU 负责系统中设备的时钟源与分频配置，一旦配置被破坏，设备就可能无法按照预期速率工作。在ZVM中，CRU 的错误操作同样具有明显的“跨 OS 破坏性”。

图5. CRU时钟与复位控制示例

如图5所示，ZVM 为设备 A 和设备 B 分别配置了不同的时钟频率：客户 OS1 中设备 A 的数据传输速率为 100 MHz，客户 OS2 中设备 B 的数据传输速率为 50 MHz。如果客户 OS1 错误地修改了 CRU 中与设备 B 相关的时钟配置，就会直接改变设备 B 的工作频率，导致客户 OS2 中的任务无法正常完成。这一示例直观说明了 CRU 隔离的重要性。

（3）SYSCON 系统级配置

SYSCON 可以被理解为系统级“功能开关总台”，用于管理 GPIO 复用、接口功能分配等关键配置。错误的 SYSCON 配置，可能导致某个物理接口被错误分配，从而影响其他客户 OS 的正常功能。

图6. SYSCON系统控制示例

在图6中，ZVM 将 GPIO-A 分配给 UART 供客户 OS1 使用，将 GPIO-B 分配给 I2C 供客户 OS2 使用。如果客户 OS1 错误修改了 GPIO-B 的 SYSCON 配置，就可能直接导致客户 OS2 的 I2C 通信失败。这一图示清晰展示了 SYSCON 若不隔离，可能带来的跨 OS 功能破坏。

04 完全虚拟化与访问监控的协同解决方案

针对上述关键设备隔离问题，ZVM 采用了完全虚拟化与精细化访问监控两种设计协同工作。

设计一：完全虚拟化。 ZVM通过为每个关键设备（如GIC、CRU和SYSCON）提供完全虚拟化的管理，这样每个客户OS只能访问和操作自己虚拟的设备资源（如vGIC、vCRU和vSYSCON）。所有客户OS的读写请求由ZVM统一处理后再与真实硬件交互。从根源上就避免了它们直接冲突，因为大家根本摸不着真家伙，确保彼此之间不会相互干扰。

设计二：精细化访问监控。 ZVM实时监控客户OS对关键设备的所有访问操作。每个客户OS只会被授权访问与自己相关的设备寄存器，而不能直接操作关键设备的全局寄存器。如图7所示，如果客户OS需要配置设备A中断，那么它也只能修改vGIC控制器，ZVM随后检查这一配置动作是否具备修改硬件的权限，如果有，ZVM才会真正配置GIC硬件中和设备A相关的寄存器，而不影响其他硬件配置（例如设备B相关寄存器），保证了设备配置的独立性。这就像是一个智能过滤器，只放行安全的、被允许的操作。

图7. ZVM 完全虚拟化与精细化访问监控

总结

通过基础硬件隔离与关键设备隔离两道防线，ZVM 为每个客户 OS 构建了独立、受保护的运行空间。Stage-2 地址转换保障了资源独立，完全虚拟化与访问监控则防止了全局性破坏。借助这些机制，ZVM 严格阻止了故障传播，为复杂嵌入式系统提供了高安全、可控的底座。

ZVM特性：高安全隔离