Quest-V：多内核 sandbox / 每 sandbox 一个 monitor / 故障与在线恢复

不是"一个 hypervisor 管所有 VM"，而是**多个 sandbox kernel，每个配一个自己的 monitor**：

sandbox domain = 一个或多个 CPU + 一块主机物理内存
                 （内含【本地 monitor】+ sandbox kernel + 本地应用）

monitor 只为【一个】sandbox 维护 EPT 映射
  → 省掉传统 hypervisor 调度/切换 guest 地址空间的开销

于是两条容易误判成"缺失"的现象其实是设计：

没有大量 VM-exit          → sandbox 自己管 I/O
没有中央调度器/全局时钟    → 每 sandbox 自己调度、自己的物理时钟

</CORE RULE>

一、monitor 什么时候才被调用

只在四件事上介入：

① 引导各内核（bootstrapping）
② 处理故障（fault）
③ 管理与发起影子页表（shadow page tables）
④ 建立 sandbox 间通信通道

其余时间 sandbox 直接在硬件上运行。

monitor 可以按每核建立，也可以为一个核的集群建立（"域/单元"）——不是天然一核一 monitor
monitor 跟踪影子页表映射，这些映射表达不可变的内存访问能力，所以 sandbox 代码无法修改"管辖主机内存访问的 EPT 映射"

二、EPT 用于内存隔离，不是 CPU 虚拟化

用 EPT/嵌套页表主要是为了内存隔离（额外一层逻辑保护环），指令直接在硬件执行
sandbox kernel 的代码段实际是只读的——因为 sandbox 代码没有访问自己 EPT 映射的途径
每个 sandbox 做自己的本地调度与设备管理

三、中断与 I/O：直接交给 sandbox

中断被定向到 sandbox kernel（I/O APIC 广播或 IPI），并在驱动里做早期解复用——避免 monitor 介入与复杂的 I/O 虚拟化
部分驱动数据结构跨 sandbox 共享，另一些是复制或同步的

四、sandbox 间通信

显式消息传递 + 共享内存通道，传缓存行大小的消息
一个 sandbox 里的服务可以访问另一个 sandbox 里的服务
IPI 用于 sandbox 间通信；APIC 机制也用于重路由中断以做远程故障恢复

五、故障路径（定位 monitor 的第一线索）

故障被检出时会产生 EPT violation → 控制权转移（VM-exit）到对应的 monitor
若某故障不会自动触发 VM-exit，故障处理器可以强制触发它（例如用某条必然陷入的指令）
sandbox kernel 只读段里的故障检测代码被假定安全
抢占超时可周期性强制陷阱到 monitor——这样检测逻辑就位于 monitor 内，与被篡改的 sandbox 隔离

六、恢复：本地与远程，都是在线的

本地恢复：monitor 释放故障组件的内存、可能重新初始化整个 sandbox、或用替代实现替换组件（功能/实现多样性），并通过调整该 sandbox 的 EPT 映射来激活替代实现
远程恢复：本地 monitor 选一个目标 sandbox（随机、轮转、或按负载），经 IPI 通知；远端 monitor 执行恢复，经消息传递从共享内存取状态
恢复在线完成，不重启整机；未受影响的 sandbox 继续正常运行

七、实操：手里这份映像，哪一段是 monitor

几个可用的判据（按可靠性排序）：

谁持有并修改 EPT 映射/影子页表——这是 monitor 独有的能力（sandbox 代码无法访问自己的 EPT 映射）
故障入口：VM-exit 的目标、以及"强制触发陷入"的那条路径
抢占超时的定时逻辑：它被刻意放在 monitor 内与被篡改的 sandbox 隔离
引导/通道建立代码：只在启动与建通道时出现

反之，大量设备驱动与本地调度逻辑属于 sandbox kernel，不是 monitor。

八、时间与迁移

没有全局时钟：每个 sandbox 有自己的物理时钟，事件计时由每核本地定时器管理，不保证同步
既没有全局调度器也没有全局时钟 → 跨 sandbox 迁移与通信的时序分析必须把时钟偏差算进去（相关研究专门推导过含时钟偏差的通信界限）
跨 sandbox 的时间戳不能按单一时间线比较

决策树

拿到多内核 sandbox 系统的映像
├─ 找不到中央 hypervisor
│    └─ 正常：每 sandbox 一个 monitor
├─ VM-exit 很少
│    └─ 正常：sandbox 自己调度与管 I/O，中断直接投递
├─ 要定位 monitor
│    ├─ 谁持有/修改 EPT 与影子页表
│    ├─ VM-exit 目标与"强制触发陷入"路径
│    ├─ 抢占超时的定时逻辑
│    └─ 引导/建通道代码
├─ 故障与恢复
│    ├─ EPT violation → VM-exit 到对应 monitor
│    ├─ 本地恢复可重初始化整个 sandbox 或换实现（改 EPT 激活）
│    └─ 远程恢复经 IPI + 共享内存传状态，全程在线
├─ 跨 sandbox 通信
│    └─ 显式消息 + 共享内存通道（缓存行大小消息）+ IPI
└─ 时间线对不上
     └─ 无全局时钟：各 sandbox 时钟不保证同步，别按单一时间线断言

工具与验证

资源：sandbox domain 到 CPU/内存/设备的映射
monitor：EPT/影子页表、故障入口、抢占超时、引导与通道建立代码
通信：共享内存通道的消息流与 IPI
时间：各 sandbox 的本地时钟与偏差
验证：能同时说清「这段代码属于 monitor 还是 sandbox kernel + 该故障经哪条路径到 monitor + 这条跨域数据的时序基准是谁的时钟」

该平台的坑（汇总）

把"没有中央 hypervisor"当系统缺失：每 sandbox 一个 monitor 是设计
把"VM-exit 很少"当没有虚拟化隔离：指令直接在硬件跑是设计
以为 monitor 参与每次 I/O：它只在引导、故障、影子页表、建通道时介入
把设备驱动当 monitor 的一部分：驱动与本地调度属于 sandbox kernel
以为能改 EPT 映射：sandbox 代码无法访问自己的 EPT 映射
把不同 sandbox 的时间戳按单一时间线比较：没有全局时钟
以为恢复一定重启整机：本地/远程恢复都在线进行
把"替代实现替换组件"当异常：那是设计内的恢复手段
假设一核一 monitor：monitor 可以按核集群建立

6.3 KiB Raw Blame History Unescape Escape