reverse-skills-max: initial public release (restored, redacted, hardened)

vendor-new/rev-skills/.claude/skills/re-hypervisor/references/xtratum.md

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