步骤 1：Guest OS 发起写入#

Guest OS 中的一个进程执行了一条写入指令，例如 STR X0, [X1]，其中 X1 寄存器里的地址是一个 Guest VA。

步骤 2：硬件 MMU 开始工作#

CPU 的 MMU 硬件开始进行两阶段地址翻译：

1. Stage 1 翻译: MMU 使用 Guest OS 的页表，将 Guest VA 成功翻译成一个 IPA。

   • 注意：如果在这里就失败了，那么只会触发 Guest OS 自己的页错误（Page Fault）异常，由 Guest OS 内核处理，KVM 不会介入。这属于虚拟机内部的正常运作。

2. Stage 2 翻译: MMU 拿到 IPA 后，接着使用 KVM 设置的 Stage 2 页表，试图将这个 IPA 翻译成一个真实的 Host PA。

步骤 3：硬件检测到错误并触发异常（Trap）#

此时，“错误”发生了。这通常是以下两种情况之一：

• 情况 A (地址不存在): KVM 的 Stage 2 页表中根本没有为这个 IPA 建立任何映射。这意味着 Guest OS 访问了一个 KVM 没有分配给它的“物理”地址。
• 情况 B (权限不足): KVM 的 Stage 2 页表中虽然有这个 IPA 的映射，但 KVM 将其标记为只读（Read-Only），而 Guest OS 却试图写入（Write）。

无论哪种情况，硬件 MMU 都会在 Stage 2 翻译阶段宣告失败，并立即：

1. 停止当前指令的执行。
2. 生成一个硬件异常（在 ARM 中称为 Data Abort）。
3. 由于这是一个由 Stage 2 MMU 引起的异常，硬件根据 KVM 的预先配置，将 CPU 的执行状态从 Guest 的 EL 1 强制切换到 Hypervisor 的 EL 2。
4. 将导致异常的详细信息存入 EL 2 的系统寄存器中，例如：
   • ESR_EL2 (Exception Syndrome Register): 记录异常的原因，例如“Stage 2 Translation Fault”或“Stage 2 Permission Fault”。
   • FAR_EL2 (Fault Address Register): 记录导致错误的 IPA 地址。

这个从 EL 1 到 EL 2 的强制切换，就是 KVM 捕获到异常的时刻，也被称为一次 VM Exit。

步骤 4：KVM 在 EL 2 中处理异常#

现在，CPU 的控制权已经交给了 KVM。

1. 分析异常: KVM 的异常处理程序开始执行。它会读取 ESR_EL2 和 FAR_EL2 寄存器，从而精确地知道：

   • 哪个虚拟机出错了。
   • 为什么出错（地址不存在还是权限不足）。
   • 出错的 IPA 地址是什么。

2. 决策与行动: 根据分析结果，KVM 会做出不同处理：

   • 模拟设备 I/O (MMIO): 如果出错的 IPA 地址正好是 KVM 为某个模拟设备（如虚拟网卡、串口）划分的内存区域，那么这次“错误”写入是预期之中的。KVM 会截获这个写入的数据，并通知用户空间的 QEMU 进程去模拟相应的设备行为。这是实现设备虚拟化的核心机制。
   • 真正的 Guest OS 错误: 如果该地址不属于任何模拟设备，也不是其他特殊情况（如写时复制），那么 KVM 就断定这是 Guest OS 内部的一个真正的内存访问错误。KVM 无法替 Guest OS 修复这个错误。
   • 注入异常: KVM 会在 Guest OS 的 vCPU 上下文中模拟一个精确的内存中止异常，然后将 CPU 控制权返回给 Guest OS（VM Entry）。

步骤 5：Guest OS 的最终反应#

Guest OS 从 KVM 返回后，会立即“感受”到 KVM 注入的内存中止异常。它会像在真实物理机上遇到内存错误一样，进入自己的异常处理流程，通常的结果是：

• 向导致错误的进程发送 SIGSEGV 信号，杀死该进程。
• 如果错误发生在内核态，Guest OS 会打印错误信息并崩溃（Kernel Panic）。