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

<CORE RULE>
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**：配置校验会失败
- **把采样端口当队列端口**：覆盖语义不同
- **以为任何分区都能控制系统状态**：只有系统分区可以
- **忽略健康监控的配置动作**：它可以直接导致计划切换或分区状态变化