XtratuM：XM_CF 配置驱动 / 调度计划 / IPVI

XtratuM 是**配置驱动**的分离 hypervisor：资源不是运行时协商的，而是由 **XM_CF 配置文件**静态规定：

分区 / 内存 / 中断 / I/O 端口 / 通信端口 / 调度

运行期不能新增动态对象。 所以看到"找不到运行时资源分配代码"，先怀疑你手上没拿到配置文件，而不是代码被裁剪。 </CORE RULE>

一、XM_CF：系统集成者与分区开发者的契约

配置是 XML，经校验后翻译成二进制形式（配置表）并集成进最终系统镜像。

主要内容：

章节	内容
内存	板级内存布局、给 hypervisor 与各分区的内存；分区内存区可带标志（未映射 / 映射到某处 / 共享 / 只读 / 不可缓存 / IOMMU）
处理器	CPU 如何分配给分区，含调度计划
外设	不由 XtratuM 管理的外设、I/O 端口范围、每个分区的中断线与设备标识
健康监控	检出错误后如何处理（直接动作 / 交给出错分区 / 记日志 / 复位…）
分区间通信	端口与通道（采样与队列两类），连接源端口与目的端口
跟踪	跟踪消息存放位置与跟踪范围

配置解析器会做语法与语义双重校验：内存区重叠/包含关系、分区名与 ID 重复、CPU 分配、端口重复、循环调度计划的一致性（分区是否都被分配、时间槽是否重叠、槽的分区 ID 是否有效）、硬件中断分配、I/O 端口对齐与占用、通道分配等。

二、两种调度：循环与优先级

循环调度（ARINC 653 风格）：(分区, 虚拟 CPU) 对被固定循环调度；时间槽在配置里以起始时间 + 时长定义；**major frame（MAF）**周期性重复，通常取各分区/线程周期的最小公倍数。

优先级调度：按配置里给分区的优先级调度（优先级 0 最高），抢占式；配成固定优先级的 CPU 不受其他 CPU 循环计划影响。

多个调度计划（关键细节）：

Plan 0 保留给初始化：系统从 Plan 0 启动，直到某系统分区请求切换
Plan 1 保留作维护计划：健康监控检出处境时可立即切到它，或由系统分区请求
设计者可定义 Plan X（X>1）
计划切换发生在当前计划的剩余槽全部执行完之后
多核下：只有循环计划与多计划关联；优先级 CPU 独立于计划；涉及多个处理器的计划必须定义相同的 MAF

调度可视为状态机：每个状态对应某分区按计划执行；next_slot 定时器中断导致上下文切换；槽时长定时器由 XtratuM 独占使用。

三、中断与分区间虚拟中断（IPVI）

配置规定分区可访问哪个设备、设备标识与该分区使用的中断线；XtratuM 负责映射设备所在的内存区
IPVI 模拟真实的处理器间中断：任何分区都可通过 hypercall 发出，向目的分区投递一个虚拟中断；每个分区最多 8 个 IPVI，实现为最后八个扩展虚拟中断
分区事件通常由分区自己处理；hypervisor 按配置中的动作提供通知机制；向端口写入/发送新消息时也可触发扩展中断（XtratuM 在分区控制表里维护端口状态位图）

四、运行期权限

只有系统分区才被允许控制系统与其他分区的状态、以及查询它们的状态。看到"某分区想改全局状态却做不到"，先看它是不是系统分区。

五、计划切换的两种时机语义

Plan 0 是复位后的初始计划，而且不能像普通用户计划那样再切回来；Plan 1 是维护计划；用户定义的计划通常从 >1 开始
普通请求的切换不是立即的：系统分区请求切换时，当前计划的槽全部跑完后（major frame 结束）才切到新计划

请求切换之后旧计划还跑了一段时间 → 完全正常

但健康监控切维护计划可以立即发生：它属于"终止当前槽、立刻开始维护计划"一类动作

所以同一个"计划变了"事件存在两种完全不同的时机语义——不能用一个模型解释全部。

同一 major frame 内多次请求：最终可以是最后一次请求指定的计划生效——不要把中间计划没有出现标成"请求被丢弃"

六、采样端口的刷新与失效

采样端口是 latest value：新消息覆盖旧消息、没有队列；刷新周期决定数据的"新鲜度"，旧数据可能被标记为无效
队列端口才是真正的"带缓冲的单播消息"——两者必须严格区分
写端口之后 guest 没收到通知：XtratuM 的对象通知使用扩展中断，而对应扩展中断在分区启动时默认是掩蔽的——"消息存在但没有中断"先查掩蔽状态

七、故障后的控制流不由出错分区决定

健康监控按 事件 / 范围 / 分区标识 / 故障地址或设备 映射到预定义动作
所以"fault 之后系统自动切了调度"必须从健康监控策略解释，不能只看出错 guest 自己

决策树

拿到 XtratuM 目标
├─ 先要配置文件（XM_CF）
│    ├─ 分区/内存/中断/I/O/通道/调度都在里面
│    └─ 没有它，关于"为什么访问不到"的判断都是猜
├─ 调度相关
│    ├─ 循环计划：MAF + 槽（起始 + 时长）+ 分区/vCPU 对
│    ├─ 优先级计划：优先级 0 最高，抢占式
│    └─ 计划切换在当前剩余槽执行完之后才发生
├─ 分区不运行
│    ├─ 查当前处于哪个 Plan（Plan 0 = 初始化，Plan 1 = 维护）
│    ├─ 查该分区是否在当前时间槽
│    └─ 查健康监控是否触发了切换
├─ 通信相关
│    ├─ 采样端口 vs 队列端口（覆盖语义不同）
│    └─ 通知可经 IPVI（每分区最多 8 个）
└─ 运行期改配置
     └─ 不可能：无动态对象；只有系统分区能控制系统状态

工具与验证

配置：XM_CF 的章节与生成后的配置表；解析器的语义校验项（可当"这份配置合法吗"的检查清单）
调度：处理器章节里的循环计划表/固定优先级表；当前 Plan 与时间槽
通信：端口表与通道定义；IPVI 的源/目的与编号
验证：能同时说清「该分区被分配了什么 + 当前处于哪个计划与时间槽 + 通信走哪个端口/通道」

该平台的坑（汇总）

没拿到 XM_CF 就分析资源归属：一切都在配置里
以为可以运行时新增对象：静态配置，无动态对象
把计划切换当请求后立即生效：要等当前计划剩余槽执行完
忽略 Plan 0（初始化）与 Plan 1（维护）的保留语义
多核下把优先级 CPU 也套循环计划：优先级 CPU 独立于计划
多处理器计划未定义相同的 MAF：配置校验会失败
把采样端口当队列端口：覆盖语义不同
以为任何分区都能控制系统状态：只有系统分区可以
忽略健康监控的配置动作：它可以直接导致计划切换或分区状态变化

7.1 KiB Raw Blame History Unescape Escape