客户 OS 自恢复机制 (Self-Recovery)
01 引言：高可用性的差异化演进
在嵌入式实时虚拟化场景中，客户操作系统（Guest OS）的稳定性直接影响业务连续性与系统可用性。针对客户OS在运行过程中可能出现的异常崩溃、失去响应等故障场景，ZVM设计并实现了一套面向不同类型客户OS的自恢复机制。该机制根据RTOS与Linux在内存规模、实时性要求及运行模型上的差异，采用差异化的恢复技术路线，以在保障恢复可靠性的同时兼顾性能与确定性。
RTOS内存体量较小，一般为几MB或十几MB，对恢复的完整性和时间确定性要求极高；而Linux内存体量较大，若照搬RTOS的恢复模式会产生显著性能损耗，且其业务场景对全量状态恢复的需求较低，因此需要针对性设计不同方案。ZVM 设计了一套面向不同类型 OS 的自恢复机制：
RTOS：快照模式
在系统运行过程中，会按既定策略将RTOS的寄存器配置、VM配置、内存全量数据等核心状态，保存到TF卡或内存备份区域；发生故障时找最近的快照点进行恢复。
Linux：轻量重启模式
无需保存全量内存数据，仅需留存VMID、VirtIO-blk块设备编号并持久化到TF卡；发生故障时，ZVM会依托VirtIO-blk块设备让Linux完成干净重启。
02 特性一：面向 RTOS 的快照式自恢复
针对内存规模较小、对实时性和状态一致性要求极高的 RTOS，ZVM 采用基于系统快照（Snapshot）的自恢复方案。其核心思想是在系统运行过程中，周期性地对 RTOS 的关键运行状态进行完整保存，以便在发生故障时实现精确恢复。
快照核心内容：
- CPU 上下文信息：包括通用寄存器、系统寄存器以及浮点寄存器，用于确保恢复后的指令执行环境与故障前保持一致。
- RTOS VM 配置数据：如 vCPU 配置、内存规模及虚拟设备状态，用于重建虚拟机运行环境。
- RTOS 全量内存数据：通过在同一时间点完整保存内存内容，保证任务状态、数据结构及关键变量的一致性。
图1. RTOS 快照机制示意
存储位置支持
- 持久化介质：存储至 TF 卡、eMMC 等掉电保持介质，实现跨重启、跨断电的持久化恢复。
- 内存快速备份：直接保存至内存中，作为运行期间的快速备份，显著缩短恢复路径。
基于心跳的触发机制
采用周期性保存策略。例如，在 RTOS 心跳周期为 1ms 时，累计若干周期后自动触发快照保存，确保拥有最近的稳定恢复点。
自动恢复逻辑：
当检测到心跳丢失或异常时，ZVM 自动加载最近一次有效快照，重建 VM 实例并恢复寄存器与内存。
性能指标：
在基于内存备份的恢复方式下，RTOS 的恢复开销接近线程调度级别，整体恢复时间控制在 25 μs 以内，满足严格的实时性要求。
03 特性二：面向 Linux 的轻量化重启式自恢复
与 RTOS 不同，Linux 通常具备更大的内存体量，若采用全量快照机制将带来显著的性能和存储开销。基于这一特点，ZVM 为 Linux 设计了基于 VirtIO-blk 块设备的轻量化自恢复方案，其本质是一种受控的快速重启机制。
在 ZVM 环境中，Linux 的启动流程采用分阶段加载方式：系统首先通过设备树启动临时根文件系统，随后由临时根文件系统挂载 VirtIO-blk 中的完整文件系统，最终切换至完整系统完成启动。基于这一启动模型，Linux 的自恢复无需保存内存运行态。
图2. Linux 重启式恢复流程
数据保存逻辑： 在恢复前，ZVM 仅需保存两类核心配置数据。一是 Linux 虚拟机的基础配置参数，包括 VMID、vCPU 数量、内存规模等；二是与之关联的 VirtIO-blk 块设备编号。通过保留上述信息，即可确保恢复后的 Linux 运行环境与故障前保持一致。
持久化存储： 相关配置数据会被统一封装为配置包，并持久化存储至 TF 卡等可靠介质。与 RTOS 的周期性快照不同，Linux 配置数据仅在虚拟机创建或配置发生变更时进行更新，从而避免了不必要的运行时开销。
触发与执行： 当 ZVM 监测到 Linux 虚拟机心跳异常或失效时，将从 TF 卡中加载预先保存的配置包，重新创建对应的虚拟机资源，并依托 VirtIO-blk 文件系统完成系统启动。该过程等价于一次干净的系统重启，具备实现简单、稳定性高的特点。
架构优势总结：
通过针对RTOS与Linux运行特性的差异化设计，ZVM构建了一套完整且高效的客户OS自恢复体系。其中，RTOS采用快照式精确恢复机制，以满足高实时性和强一致性的要求；Linux则采用基于VirtIO-blk的轻量化重启恢复方案，在保障可靠性的同时有效降低系统开销。该体系具备良好的扩展性，可根据具体业务场景和设备特性，对不同类型客户OS及外设进一步定制恢复策略。