1. 课程导入
在嵌入式、工业控制、汽车电子与边缘计算领域，系统对实时性、确定性和安全隔离的要求越来越高。传统虚拟化方案如 KVM、Xen 虽然功能强大，但往往依赖复杂的调度器和庞大的管理程序，带来不可预测的延迟与较高的资源开销。Jailhouse 正是在这样的背景下出现的一种静态分区虚拟化方案：它不追求通用性，而是把物理硬件资源在启动时“一次性切分”给若干彼此隔离的分区，让每个分区像独占一台机器一样运行。
理解 Jailhouse，关键要抓住“静态”二字。与动态调度虚拟机不同，Jailhouse 在系统启动阶段就完成 CPU 核、内存区域、外设中断和 PCI 设备的分配，运行期不再进行资源迁移和抢占式调度。这种设计牺牲了灵活性，却换来了接近裸机的执行效率和可验证的时间行为，因此特别适合对确定性要求苛刻的场景。
核心原理：从“管理”到“切分”
Jailhouse 的架构可以概括为“一个轻量 Hypervisor + 若干静态分区”。Hypervisor 本身代码量很小，通常只负责分区创建、CPU 核的进入与退出、中断路由和少量通信机制。真正的设备驱动仍然运行在各个分区内部，而不是集中在管理程序中。这样做的直接好处是：驱动崩溃被限制在分区内，不会拖垮整个系统。
Jailhouse 使用 cell（单元）来描述一个分区配置。每个 cell 配置文件中声明了该分区可用的 CPU、内存、中断和 PCI 设备。系统启动后，root cell 先运行 Linux，再由 root cell 中的 jailhouse 工具加载并激活其他 inmate cell。下面是一个简化的 cell 配置片段：
struct jailhouse_cell_desc {
.name = "inmate-linux",
.cpu_set = { 0x2 }, /* 使用第 2 个 CPU 核 */
.memory_regions = {
{ .phys_start = 0x80000000, .size = 0x10000000 },
},
.irqchips = { ... },
.pci_devices = { ... },
};可以看到，配置中没有任何“调度权重”或“时间片”参数，只有明确的资源归属。这正是静态分区虚拟化的本质：资源归属在启动时确定，运行期不再改变。
发展背景：为什么需要静态分区
Jailhouse 最初由西门子开发，后来成为 Linux 基金会下的开源项目。它的出现并非偶然，而是多重需求叠加的结果。第一，工业与汽车领域需要功能安全隔离，例如把安全关键任务与普通信息娱乐系统放在同一 SoC 上，但必须保证互不影响。第二，实时控制场景无法接受虚拟化调度带来的抖动，需要分区独占 CPU 和内存。第三，多核 SoC 普及后，硬件本身已经提供了足够的隔离基础，缺的只是一个足够轻的软件层来“划界”。
与 KVM 相比，Jailhouse 不依赖 Linux 作为宿主，而是直接运行在裸机上；与 Xen 相比，它没有复杂的域调度和驱动域模型。它的定位非常明确：用最小的软件代价，换取最强的隔离确定性和接近原生的性能。
学习目标与整体课程框架
本课程共 30 章，围绕“能理解、能配置、能调试、能落地”四个层次展开。学习完成后，你应该能够独立完成 Jailhouse 的环境搭建、cell 配置编写、分区启动与调试，并理解其在工业与汽车场景中的工程取舍。
| 阶段 | 主要内容 | 能力目标 |
|---|---|---|
| 基础认知 | 定义、架构、与 KVM/Xen 对比 | 说清静态分区虚拟化的适用边界 |
| 环境搭建 | 硬件要求、内核配置、编译与安装 | 在目标板上跑通 root cell |
| 配置实战 | cell 文件、CPU/内存/中断/PCI 分配 | 独立编写并激活 inmate cell |
| 调试与优化 | 日志分析、常见故障、性能验证 | 定位启动失败与隔离异常 |
| 工程落地 | 工业控制、汽车、边缘计算案例 | 完成方案选型与部署评估 |
典型场景与常见误区
一个典型的应用场景是：在一块多核 ARM SoC 上，CPU0 和 CPU1 运行 Linux 负责网络与人机界面，CPU2 运行裸机实时任务控制电机，CPU3 运行另一个 Linux 分区处理视觉算法。三个分区通过共享内存或 Jailhouse 提供的通信机制交换数据，但任何一个分区崩溃都不会影响其他分区继续运行。