【Jailhouse 文章】Look Mum, no VM Exits

Ramsauer R, Kiszka J, Lohmann D, et al. Look mum, no VM exits!(almost)[J]. arXiv preprint arXiv:1705.06932, 2017.

本文提出了一种基于 Linux 的、与操作系统无关的分区Hypervisor —— Jailhouse，它将 Linux 与严格隔离的系统相结合。本文设计目标是尽量减少代码量并尽可能减少 Hypervisor 对 GuestOS 的干涉。Jailhouse 将硬件直接分配给 GuestOS，从而将复杂的硬件处理引导问题从Hypervisor转移到通用操作系统(GuestOS)。Jailhouse 建立隔离域，且能够直接访问物理资源，无需仿真或半虚拟化。Jailhouse不仅保留了 Linux 操作系统的通用性，还利用自身简洁的优势，使得实现安全关键性和实时关键性工作负载在隔离域中运行变得容易。

1. Introduction

安全关键和非关键产品的制造商倾向于将不同关键级别的组件拆分到不同硬件上实现，比如不同的物理CPU执行不同关键级别的任务。传统的混合临界环境中，单个控制任务与专用的物理控制硬件绑定，一种典型的物理控制器是可编程逻辑控制器（PLC），其中一辆车能够包含数十个到一百个不同的控制器，将这些系统整合到单个硬件控制器中是一种架构趋势[4]，因为不仅可以提高软件的可维护性，还能够降低整体硬件的成本。本文的方法利用 CPU 虚拟化扩展技术创建执行环境，使用静态分区技术划分硬件资源，能够将现有的程序移植到严格隔离的执行域中。

Jailhouse 通过向系统和 I/O 总线插入“虚拟屏障”，将对称多处理 (SMP) 系统转换为非对称多处理 (AMP) 系统。从硬件的角度来看，系统总线仍然是共享的，但是GuestOS（囚犯）仅仅能够使用部分物理硬件，就好像被囚禁在牢房中。

Jailhouse 由启动运行的 Linux 系统中的内核模块启用。Jailhouse 控制所有硬件资源，根据系统配置将它们重新分配给 Linux，并将 Linux 提升到虚拟机状态（虚拟机）。Jailhouse 的 Hypervisor 核心充当虚拟机监视器 (VMM)。该方案不适用于传统的 Hypervisor 分类 [8] —— 它可以被视为 Type-1 和 Type-2 Hypervisor的混合：它像裸机 Hypervisor 一样在原始硬件上运行，没有底层操作系统，但是如果没有 Linux 作为助手来提供初始化硬件的功能，Jailhouse 仍然无法运行。Linux 用作引导加载程序，但不用于管理系统。与其它旨在管理硬件资源并禁止 GuestOS 系统直接访问实时分区的方法（例如，PikeOS [10]）不同，Jailhouse 仅支持直接硬件访问。Jailhouse 没有使用复杂且耗时的（半）虚拟化 [2] 方案来模拟设备驱动程序并共享物理硬件资源，而是采用类似 exokernel 的方法 [7]，因为它只提供隔离（通过利用虚拟化扩展），不提供调度程序也不提供虚拟 CPU。

本文主要内容：

• Jailhouse 的架构，一个运行在多个架构上的功能齐全、非调度、实时、静态分区和开源Hypervisor。
• 运行混合关键性应用程序的样例。
• 延迟虚拟机 Hypervisor 激活的优势。
• Nvidia Jetson TK1 中断系统的典型微基准测试

2. Related Work

虽然 Hypervisor 通常针对桌面和企业领域的高吞吐量和最佳性能进行优化，但针对实时嵌入式系统的虚拟化解决方案尤其针对低延迟、确定性计算周期和保持实时能力较为不足，许多嵌入式虚拟机 Hypervisor 采用经典虚拟化的既定做法：过度虚拟化硬件、半虚拟化 [2] 或设备仿真，以及 GuestOS 调度。

克雷斯波等人介绍了 XtratuM [5] 嵌入式 Hypervisor。他们的方法侧重于航空电子指南和规范给出的设计约束。他们重点介绍了 Xtratum 上的内存管理、时钟和定时器管理、中断管理、功能丰富的超级调用接口和自己的调度程序。XtratuM 是一个成熟的虚拟机Hypervisor。

PikeOS [10] 允许执行不同的 GuestOS 或本地任务。对于运行的客户操作系统，PikeOS 使用半虚拟化和硬件辅助虚拟化，但也允许直接 I/O 访问。对于应用程序调度，PikeOS 结合了时间和优先级驱动的调度，并对非关键任务使用尽力而为的调度。

为了实现时间和空间隔离，Hypervisor 并不总是需要所有的虚拟化扩展功能。平托等人[16] 通过利用 ARM TrustZone 技术在单个 CPU 上与 Linux 并行运行实时操作系统。他们的方法通过仅对实时关键设备使用快速中断 (FIQ) 来保持实时功能。与常规 IRQ 相比，这些中断直接到达实时操作系统和 Hypervisor 执行的安全世界。正常中断到达与安全世界隔离的非安全世界，这种方法仅将非安全世界与安全世界隔离。此外，TrustZone 方法只允许创建两个域。

Quest-V [12] 是 Quest 操作系统的一个进步，在几个方面与 Jailhouse 相似。它旨在以最少的 Hypervisor 活动进行静态硬件分区。与 Quest-V 相比，Jailhouse 只是一个 VMM，并没有实现任何设备驱动程序，这大大减少了其代码库。Quest-V 依靠半虚拟化方案来引导 Linux 内核作为 GuestOS。

与所有这些系统相比，Jailhouse 从 Linux 开始（并利用其初始化大部分硬件的能力），然后使用延迟（或延迟）虚拟机 Hypervisor 激活 [18] 将硬件分区到已经运行的 Linux 下。

3. Static Hardware Partition

3.1 Jailhouse Philosophy

如图所示，激活 Jailhouse 的工作是在包含 Hypervisor (HV) 的 Linux 内核模块的帮助下完成的，在每个 CPU 执行完 HV 启动代码后，Linux 继续作为J ailhouse 的 Guest 运行（一个 cell），即 root cell。

Linux 是硬件支持完善充分的操作系统，Jailhouse 利用这一优势使用了 Linux。Jailhouse 的非典型延迟激活过程具有相当大的实际优势，即大部分硬件初始化完全下沉到 Linux，并且 Jailhouse 可以完全专注于管理虚拟化扩展。与 exo-kernel [7] 方法类似，Jailhouse 是一个 exohypervisor。硬件设备的直接分配允许 Linux 像以前一样继续执行。与其他分区方法（例如，[12]）不同，Jailhouse 不需要任何特定的设备驱动程序。

Jailhouse 假设物理硬件资源不需要在 GuestOS 之间共享。为了创建额外的域（称为non-root cell），Jailhouse 从 Linux 中“释放”硬件资源（例如 CPU、内存、PCI 或 MMIO 设备）并将它们重新分配给新域。这包括物理 CPU：cell 的配置文件中至少包含一个 CPU 和一定数量的内存，这些内存由具有辅助操作系统或裸机应用程序的 root cell 预加载。

Linux 使选定的 CPU 脱机并调用 Hypervisor，通过提供描述分配资源的 cell 配置文件来创建新 cell。其他资源，如 PCI 设备、内存映射设备或 I/O 端口，也可以重新分配给新 Guest(cell)。Hypervisor 阻止从任何其他域中对这些资源的访问。non-root cell 可以被动态创建、销毁（即，将资源分配回root cell）或重新启动。

由于 Jailhouse 只重新映射和重新分配资源，理想的设计理念是除了管理任务之外它不需要在设置和启动所有 GuestOS 后仍然处于活跃状态，并且只在访问冲突的情况下进行拦截：“No VM exists!”，但是，硬件（尚未）完全适合这种方法，因此在当前的硬件上，以下情况仍然需要 VMM 的干预：

• 中断重新注入（取决于架构，中断可能不会直接到达 Guest）
• 拦截不可虚拟化的硬件资源（例如，ARM 上的通用中断控制器 (GIC) 的一部分）
• 访问平台细节（例如，访问控制协处理器 CP15 或 ARM 上的电源状态控制接口 (PSCI)）
• 某些指令的仿真（例如 x86 上的 cpuid）

以下陷阱是不可避免的，并且与本文的概念不矛盾，因为它们仅在jailbreak或cell管理的情况下发生：

• 访问冲突（内存、I/O 端口）
• cell管理（例如，创建、启动、停止或销毁cell）

这些拦截会引入开销和延迟 —— 这是当然的，因为虚拟化是有代价的 [6]。在第四节中，本文示例性地介绍了对一个基本微基准的评估，即中断的额外延迟。

尽管 GuestOS 之间的资源严格隔离，Jailhouse 仍然允许 cell 共享物理页面。除了满足 cell 间通信外，还允许共享内存映射的 I/O 页面，如果需要，这允许从多个域内访问硬件资源。然而，这种并发访问不是由 Jailhouse 仲裁的，需要由 GuestOS 适当地解决。

如图显示了三个 cell 的可能分区系统布局：Linux 根cell（绿色）、一个附加的 Linux non-root cell（蓝色）和一个极简实时操作系统（红色）。cell 之间的通信是通过共享内存区域以及信令接口实现的，这种极简设计在 Hypervisor 中不需要额外的设备驱动逻辑。根据硬件支持，cell 间通信通过 MessageSignaled Interrupts (MSI-X) 或传统中断基于虚拟 PCI 设备实现。GuestOS 可以使用此设备在其上实现虚拟以太网设备。在没有 PCI 支持的系统上，Jailhouse 模拟一个通用且简单的 PCI 主机控制器。

3.2 Support

分区方法允许经过安全认证的操作系统或裸机应用程序在与 Linux 并行的多核系统上运行。值得一提的是，尽管 Jailhouse 支持四种不同的 CPU 架构，超出了许多实验或研究系统所提供的架构，但其极简的方法导致核心部分的代码只有几千行。这简化了认证过程，但允许开发人员专注于重要问题，而无需花费时间提供系统在生命周期内都不会用到的驱动程序。核心代码的简洁是对 Hypervisor 进行形式验证的良好基础，类似于相关系统软件的形式验证 [11]。

Jailhouse 带有自己的 inmate library，允许运行简约的演示应用程序。除了 Linux 之外的几个操作系统已经可以作为 Jailhouse GuestOS 使用（x86 [3] 上的 L4 Fiasco.OC、ARM 上的 FreeRTOS、ARM64 上的 Erika Enterprise RTOS v3）。本文以非常有限的努力成功地为 ARM 架构移植了 RTEMS 实时操作系统。

3.3 Practicability

为了证明本文的方法特别适用于实际应用，本文设计了一个（混合临界）多旋翼控制系统。对此类平台的要求可与许多常见的工业设备相媲美：飞行堆栈是系统中具有高可靠性要求的安全和实时关键部分，负责飞机的平衡和导航。传感器值必须以高数据速率进行采样、处理并最终用于控制转子。对于安全可靠的任务，控制回路必须做出确定性响应。系统崩溃可能会导致真正的崩溃并带来严重后果。

飞行堆栈在 Jailhouse cell 中运行，而非关键任务，例如与地面站的 WiFi 通信或摄像头跟踪，由于可用的 Linux 软件生态系统，可以在非关键部分轻松实现。关键硬件组件，例如 SPI、I2C 或 GPIO 设备，被分配给关键 cell。本文的硬件平台是带有四核 Cortex-A15 ARMv7 CPU 的 Nvidia Jetson TK1，连接加速度计、GPS、指南针和陀螺仪的传感器板。两个物理 CPU 分配给非关键部分，两个物理 CPU 分配给关键部分。

关键域执行具有 Preempt_RT 实时内核扩展的第二个精简 Linux 操作系统。Ardupilot 提供飞行控制，除了板支持之外不需要修改。这意味着现有应用程序可以毫不费力地部署在 Jailhouse 中，并且适用于基于现有组件的实时安全关键系统。

4. EVALUATION

如前所述，Jailhouse 的目标是尽可能减少 VMM 的活动。尽管这在理论上是可能的，但存在 VMM 便会引入额外的延迟 [6]，而没有 VMM 则不会存在这些延迟。

为了评估和确定管理程序的（实时）性能，必须考虑几个环境条件。用一个单一的标量来量化管理程序的开销是困难的，甚至是不可能的。由于论文篇幅有限，本文将示例性地详细介绍中断延迟的测量，并描述其他重要的测量。

需要注意的是，此类基准测试并不衡量管理程序的开销，而是衡量管理程序在特定硬件平台上运行时的开销。尽管如此，这些测量仍然可以得出管理程序性能的趋势。

a) 超级调用：管理程序的一个典型基准是超级调用的成本。在 Jailhouse 的情况下，不需要考虑超级调用，因为它们仅用于单元管理目的，并且永远不会出现在热路径中。

b) 共享系统总线：不同的 guests 异步访问内存。尽管在受支持的体系结构上不会发生饥饿，但内存或 I/O 总线的大量使用可能会导致 Guests 显着变慢。虽然这个问题在 SMP 应用程序中是众所周知的，但在异步执行为单核平台设计的多个有效负载时，必须评估其影响。

c) 依赖于架构的陷阱：由于架构限制，Jailhouse 需要模拟硬件平台所必需且无法在硬件中虚拟化的设备（例如，作为 ARM 架构上通用中断控制器的一部分的中断分发器）。根据这些设备的使用情况，必须分析管理程序的影响。

d) 中断延迟：Jailhouse 支持两个版本的 ARM 通用中断控制器，GICv2 和 GICv3 [13, 14]。两种实现都有相同的架构限制：中断不会直接到达 Guest。它们到达管理程序，然后作为虚拟 IRQ 重新注入 Guest。这会造成管理程序中的开销，因为它必须将中断重定向到适当的 Guest，然后切换特权级别。

本文的自动测量设置包括一个 Nvidia Jetson TK1（四核 Cortex-A15 @2.32GHz）作为目标平台，以及一个用于执行实际测量的 Arduino Uno 硬件。

为了测量这种延迟，本文将裸机延迟（即没有管理程序的最小延迟）与存在管理程序时的延迟进行比较。Arduino 会定期触发目标板上的 GPIO 引脚，从而导致中断。非根单元的唯一任务是通过切换另一个 GPIO 尽快响应中断。因此，本文实现了一个使用 Jailhouse 自己的 inmates library 的简约 GuestOS。为了最小化响应的代码大小以使其尽可能快，用于切换 GPIO 的指令直接用汇编程序编写在中断向量表中。没有管理程序的测量代表所选硬件平台可实现的最小延迟。存在和不存在虚拟机管理程序的延迟差异衡量了当虚拟机管理程序和其他 Guest 异步访问系统总线时引入的延迟。Uno 的确保以 62.5ns 的分辨率进行精确测量。为了验证测量结果，本文使用示波器手动测量的延迟验证了样本测量值。

本文在几个条件下重复测量（例如，将负载放在其他客户机上以测量对共享系统总线的影响）并给出算术平均值以及标准偏差和最大延迟。每次测量运行四个小时，并以 10Hz 和 50Hz 的中断频率重复，以确定测量频率的影响。结果可以在表中找到。前两行显示了在没有管理程序存在的情况下测量的最小中断延迟，与其他测量的差异表示管理程序引入的开销。

虚拟机管理程序引入的延迟并不明显取决于中断频率，而是取决于相邻 Guest 的利用率。这种影响是由共享系统总线引起的：管理程序想要访问调度中断所需的内存，而其他 Guest 异步访问同一总线。

平均而言，中断延迟约为 810ns，偏差很小。尽管如此，异常值仍会导致近 5µs 的延迟。与典型工业通信总线系统的周期时间相比，最大延迟对于许多应用来说是可以接受的。

5. DISCUSSION

Jailhouse 的简约设计方法产生了可管理数量的源代码行 (SLOC)。 这对于学术角度的形式验证和工业角度的系统认证都是至关重要的因素（本文意识到，除了 Linux 内核之外，还需要大量软件链（例如 UEFI 固件代码、引导加载程序等）来进行引导过程，并且在某种程度上需要在此类认证中加以考虑）。

Jailhouse 总共包含用于四种不同架构的近 30k SLOC。这包括管理程序核心、示例代码、内核驱动程序以及用户空间工具和工具脚本。代码的大部分是独立于架构的。跨所有架构共享的公共关键管理程序核心代码总计不到 3.4k SLOC。x86 的体系结构相关代码约为 7.4k SLOC，并同时实现了 Intel 和 AMD，以及 ARM（ARMv7 和 ARMv8）约为 5.4k SLOC。

许多系统研究都是从零开始的，并且在重新实现现有设备驱动程序上花费了巨大的精力。但是，缺少设备支持仍然是其实用性的主要障碍。 Quest-V 超过一半的源代码行（≈140k SLOC 中的 70k SLOC）是设备驱动程序。XtratuM 具有近 27k 的 SLOC，比 Quest-V 更轻量级，并且仅实现了用于调试输出的基本驱动程序。尽管如此，Quest-V 和 XtratuM 的公开版本目前仅支持 x86 架构。

Jailhouse 故意不遵循经典的虚拟化方法，但其设计通常不会消除这些技术的使用。这为将 Jailhouse 用作实验系统平台提供了可能性，该平台允许将注意力集中在实际问题上，而不是从头开始重新实现基础。Jailhouse 是调查 AMP 工作负载下的硬件和软件行为的理想平台。此外，它为在原始硬件上执行类似数字信号处理 (DSP) 的工作负载提供了一个方便舒适的环境。

现代多核系统已经提供了足够的物理 CPU，使得许多实际嵌入式用例无需在管理程序中进行调度。事实上，实时嵌入式管理程序 [5] 的许多基本要求，例如实时调度策略、高效上下文切换或确定性管理程序调用，甚至不需要在 cell 配置文件中解决。由于 Jailhouse 不会虚拟化 CPU、过度虚拟化硬件或进行分区调度，因此不会出现昂贵的分区上下文切换或调度问题 [23]。超级调用仅用于管理目的，而不用于调节对共享硬件的访问。

根据中断系统和架构，中断可能会到达管理程序。在这样的平台上，向 Guest 重新注入中断是管理程序的一项常见工作，它会引入意外的额外中断延迟。对于支持中断重映射的 64 位 x86 架构，这个问题已经得到解决，并且将在未来实现 GICv4 [14] 规范的 ARM 架构中得到解决，这有利于本文的最终目标，即 no VM exists!。

然而，硬件设计造成的陷阱是不可避免的。在当前的 ARM 架构上，中断分配器必须是虚拟化的。Varanasi 和 Heiser [22] 假设这不会导致性能问题。在本文的实现过程中，本文观察到带有 Preempt_RT 实时补丁的 Linux 内核大量使用了中断分配器，这导致了管理程序的高活动。此类问题应通过适当的硬件设计来解决，以便能够执行未修改的 Guest。

6. CONOLUTION AND FUTURE WORK

静态分区管理程序技术是一种用于嵌入式实时虚拟化的有前途的方法，因为他们最大限度地减少与 GuestOS 交互。与半虚拟化技术相比，直接将硬件分配给 GuestOS 允许运行未经修改的应用程序，而没有管理程序开销。极简的虚拟机管理程序核心简化了认证工作。通过以访客身份执行标准操作系统，本文还最大限度地减少了移植现有传统有效负载应用程序所需的工作量。通过实现一个复杂的演示平台，本文成功地展示了硬件分区的实用性。

虽然当前硬件提供的标准虚拟化扩展似乎足以直接实现本文和许多其他方法，但实际硬件存在许多限制，这些限制可能完全破坏基于分区和虚拟化的方法的优势和保证。本文未来的工作将解决出现的问题并专注于评估管理程序的性能。