KVM内存虚拟化核心机制：MMU Notifier回调原理与实战解析

在 KVM 的代码里泡久了你会发现一个很有意思的现象：真正决定虚拟机内存语义的往往不是 vCPU 那套热路径，而是那些平时不怎么被注意的“旁路机制”。MMU Notifier 就是其中最典型的一个。它要解决的是 KVM 虚拟化里非常底层的同步问题——宿主机想回收、迁移、重新映射某个物理页之前，必须先让 KVM 把 EPT 里对应的影子页表项拆掉或更新，否则 Guest 会继续访问一块已经不属于自己的内存。换句话说，它定义的是操作系统页表改动方和 KVM 之间“谁负责通知、谁负责善后”的边界。

这篇文章我从 KVM 的角度把这条线完整拆一遍：为什么需要它、内核的观察者框架怎么搭、KVM 注册了哪些回调、每个回调在什么场景触发，以及实际调试中容易踩的锁和竞态。适合正在啃 KVM 内存虚拟化源码、准备处理 virtio-mem、内存热插拔、KSM、设备直通相关问题的内核开发者。全文基于主线内核 x86 实现的通用逻辑，具体函数名以你手上的内核版本为准。

1. 先说清楚一个核心问题：Guest 物理内存的页表由谁在管

1.1 两层页表叠起来之后，问题就变了

普通进程的地址翻译只有一级：MMU 把虚拟地址 VA 经过页表翻译成物理地址 PA，内核负责维护这张页表。到了 KVM 虚拟机里，地址翻译变成了两级：Guest 虚拟地址 GVA 先经过 Guest 自己的页表翻译成 Guest 物理地址 GPA，再经过 EPT/NPT 二级地址翻译翻译成宿主机物理地址 HPA。硬件在 CPU 内部完成这两级翻译，对 Guest 来说它看到的是一块连续的“物理内存”，但实际上这块内存映射到宿主机某个进程地址空间的若干物理页上。

问题就出在这：宿主机的物理页不是静态的。内存回收可能把匿名页换出到 swap，内存规整可能移动页的物理位置，mprotect 可能把页表改成只读，KSM 可能把内容相同的匿名页合并成一个只读共享页。这些操作发生的时候，内核维护的是宿主机进程的页表，而 KVM 的 EPT 页表是独立存在的一套影子结构。如果没有一套同步机制，EPT 里就会残留指向旧物理页的映射，Guest 一旦访问，访问的就是已经被回收或迁移走的旧页。

1.2 反向映射机制先定位到 KVM 的影子页表项

KVM 建立 EPT 映射的时候，不只是往页表里填一个 entry 就完事了，还必须把这段映射关系挂到目标物理页的反向映射链上。Linux 内核的 rmap（reverse mapping）机制遍历某个物理页的所有映射时，通过 page->mapping 和 anon_vma 可以找到所有映射它的 VMA，再通过 VMA 里的 pte 定位到具体页表项。

KVM 的影子页表项和普通进程页表项长得完全不一样，它由 KVM 自己管理，内核对它“只可远观不可亵玩”。所以 rmap 遍历到 KVM 的映射时，不能像处理普通 PTE 一样直接置空或者改标志位，它需要通过 mmu_notifier 注册的回调函数，让 KVM 自己在合适的时机去拆 SPTE、刷 TLB。把“发现页表变化”和“处理页表变化”拆成两端，中间用事件回调衔接，是这套设计最核心的抽象。

1.3 MMU Notifier 本质上是观察者模式

把 mmu_notifier 理解成发布-订阅模型最直观：mm 结构体是被观察对象，KVM 是观察者，内核页表操作路径是事件源。某个进程地址空间的页表发生特定变化时，事件源调用 mmu_notifier 的一系列辅助函数，把事件广播给所有注册在这个 mm 上的观察者。

搞清楚这个模型之后，你排查问题的时候思路就会清晰很多：事件没有发出来，那是内核核心路径的问题；事件发出去了但 KVM 处理漏了路径，那是 KVM 回调的问题；事件触发了但锁顺序不对导致死锁，那是两个模块之间的问题。我自己遇到的大部分疑难杂症，最后都归到了第三类。

2. 核心数据结构与回调注册：一次内核级“订阅”过程

2.1 mmu_notifier_ops 里到底有哪几类回调

KVM 在创建虚拟机的时候，会把自己的 mmu_notifier 实例注册到 QEMU 进程的 mm_struct 上。注册时传的核心是一个 ops 结构体，里面定义了 KVM 对各种页表事件的响应函数。主线内核上 KVM x86 的注册大概是这个样子：

c复制static const struct mmu_notifier_ops kvm_mmu_notifier_ops = {
    .invalidate_range_start = kvm_mmu_notifier_invalidate_range_start,
    .invalidate_range_end   = kvm_mmu_notifier_invalidate_range_end,
    .clear_flush_young      = kvm_mmu_notifier_clear_flush_young,
    .clear_young            = kvm_mmu_notifier_clear_young,
    .change_pte             = kvm_mmu_notifier_change_pte,
    .release                = kvm_mmu_notifier_release,
};

各回调的核心用途如下：

看这张表就能理解，KVM 的 notifier 回调覆盖的不只是“映射没了怎么办”，还包括“映射变了怎么办”“页面还年轻吗”这些内存管理子系统的深层次需求。只盯着 invalidate 回调，会漏掉一半的语义。

2.2 注册必须持有 mmap_write_lock

mmu_notifier_register 不是随便找个上下文就能调用的，它要求调用者已经持有 mm 的写锁。原因很直白：注册的过程中，可能有另一个线程正在操作这个地址空间的页表，如果不在同一把锁的保护下完成订阅，就可能出现“旧映射没通知到、新注册的观察者不知道”的空窗期。

KVM 的注册时机是在 /dev/kvm 打开并创建虚拟机时，对 current->mm 注册。正常情况下这个 current 就是 QEMU 进程，所以 KVM 监听的是 QEMU 整个进程地址空间的页表变化。注册的时候 KVM 已经默认持有 mmap_write_lock。注销同样是严格对称的，必须在写锁下进行。这个约束在写自己的内核模块时很容易踩，不持锁直接调用，lockdep 会立刻报出警告。

2.3 event 类型：同样是 invalidate，语义并不一样

mmu_notifier_range 里带了一个 event 字段，它区分了不同的页表变化原因。常见的有 MMU_NOTIFY_UNMAP（映射彻底消失）、MMU_NOTIFY_CLEAR（映射被清除但保留 VMA）、MMU_NOTIFY_PROTECTION_VMA（仅把页表范围改成只读，映射本身还在），以及软件脏页跟踪相关的 SOFT_DIRTY 事件。

为什么要区分得这么细？因为 KVM 对不同事件的响应成本完全不同。映射彻底消失时，KVM 必须无条件拆除所有 SPTE，不然 Guest 访问就会踩到悬空物理地址。而 PROTECTION_VMA 这类事件，如果 KVM 查一下发现区间内本来就还没有建立 SPTE，那完全可以直接跳过，节省一次无谓的锁和 TLB flush。理解这些事件语义，比背函数签名重要得多，实际排查时你会发现很多 bug 都是因为某个新引入的调用路径用了错误的事件类型。

2.4 blockable 语义：不是所有通知都允许睡眠

从内核 4.x 开始，mmu_notifier 引入了 blockable 的概念。原因是像 NUMA balancing、页迁移写保护这类路径，可能是在持有 mmap_read_lock 的情况下进入 invalidate_range_start 的，而读锁下回调不允许睡眠。所以 range 里会标明这个通知是否可阻塞。KVM 回调会先检查这个标志：不能阻塞时，如果发现当前操作可能因为拿不到锁或需要刷 TLB 而睡眠，就必须立刻返回失败，让上层重新走允许阻塞的路径。

这块不搞清楚，写自己的外置模块时很容易翻车。我在一次调试中见过一个第三方驱动在 invalidate_range_start 里直接调用 synchronize_rcu，结果在 NUMA balancing 路径上直接睡死，系统完全卡住。正确做法是先判断 blockable，false 的情况下该放弃就放弃。

3. KVM 侧三个关键回调的实现逻辑

3.1 invalidate_range_start：拆除 EPT 映射的主战场

invalidate_range_start 是 KVM 处理页表失效的核心函数，它的逻辑可以概括为三步。第一步，把 mmu_notifier_range 里的 hva 起始和结束地址换算成对应的 gfn 范围；第二步，遍历所有命中范围的 memslot，在 kvm->mmu_lock 下把区间内的 SPTE 清掉或者做写保护；第三步，根据情况调用 kvm_flush_remote_tlbs，使所有 vCPU 的 TLB 中相关条目失效。

这里有一个容易被忽略的细节：清掉 SPTE 不等于立刻释放物理页，因为 KVM 的 EPT 结构本身还引用着这个页，必须等待 TLB flush 完成、确认所有 vCPU 都不再缓存这条映射之后，宿主机才能真正把这个物理页回收掉。这套流程和 CPU 普通页表的 zap 流程如出一辙。清完之后，Guest 再访问这块地址就会触发 EPT violation，KVM 在 fault 处理中重新建立映射，而此刻宿主机的 PTE 已经反映了最新状态。

3.2 change_pte：性能优化的快速通道

change_pte 回调代表的场景是：映射还在，但 PTE 指向了另一个物理页，典型如 KSM 合并之后多个进程的 PTE 被改成指向同一个只读合并页。如果每次这样的变化都走 invalidate_range_start 全量拆 SPTE，Guest 再访问时重新 fault，虽然语义正确但性能损耗明显。

所以内核提供了 change_pte 快速路径，它允许 KVM 在持有锁的情况下直接找到 hva 对应的 SPTE，把 SPTE 的 pfn 更新成新的物理页，不需要拆掉重建，Guest 侧完全无感。KVM 对应的实现是 kvm_mmu_notifier_change_pte，内部会调用 kvm_set_spte_hva 去更新影子页表项。这条路径在 KSM 合并大量同类内存页、或者某些数据库高频执行 mprotect 的场景下，收益非常明显。

3.3 clear_flush_young / clear_young：回收前必须先问 KVM

Linux 内存回收需要知道一个页面最近是否被访问过，依据是页表项里的 Accessed 位。但在虚拟机场景下，Guest 访问内存时命中 EPT，CPU 更新的是 EPT 里的访问位，普通进程页表的 Accessed 位不会被置位。这样回收模块就无法判断页面是否活跃。解决方式就是通过 notifier 的 clear_flush_young 回调，让 KVM 去检查并清除 EPT 中对应 SPTE 的访问位，必要的时候刷一次 TLB。KVM 内部的实现对应 kvm_age_hva 和 kvm_test_age_hva。

这组回调平时没人关注，但内存压力上来的时候，它们对回收决策的影响非常大。如果 KVM 的 clear_young 实现有 bug 导致一直返回“页面被访问过”，那么虚拟机的匿名页在回收时就会被认为全部活跃，直接拖垮宿主机的回收效率。我调过类似问题，表象是宿主机内存明明很紧张却迟迟不回收，ftrace 一抓才发现是 notifier 回调没被正确调用。

4. 真实场景演练：madvise、页迁移、KSM、Balloon 各怎么走

4.1 场景一：QEMU 对内存执行 madvise(DONTNEED)

virtio-balloon 膨胀时，Guest 通过 virtio 协议把一部分 GPA 告诉 QEMU，QEMU 拿到对应的 hva 后执行 madvise(MADV_DONTNEED) 把这块内存返还给宿主机。这个系统调用会走进 unmap_page_range，然后触发 invalidate_range_start/end。

事件发出后，KVM 把该 hva 对应到 gfn 范围，解除所有 SPTE，并将相关 TLB 条目刷掉。此时 Guest 如果还去访问这个地址，会产生 EPT violation，KVM 会重新建立映射，把它 fault in 回来。所以 balloon 膨胀状态下 Guest 访问这些页必然伴随性能损耗，这不是 bug，而是语义本身决定的。调试 balloon 问题时，可以从 trace 里观察 invalidate_range 的触发频率，快速判断膨胀路径是否正常。

4.2 场景二：页迁移与透明大页的 split/collapse

内核进行页迁移时，为了保证迁移过程中没有其他映射在访问旧页，会先把旧页的所有映射写保护或者移除，再复制页面内容。这个过程本身就会通过 rmap 遍历最终调用到 mmu_notifier。KVM 收到通知后拆掉对应 SPTE，迁移结束时 Guest 通过 EPT violation 重新建立到新物理页的映射。

透明大页的 collapse 也有类似逻辑，多个普通页会被合并成一个 hugepage，底层物理页完全变化。如果 mmu_notifier 在这条路径上漏了通知，KVM 的 SPTE 会继续指向已经释放的旧物理页，后果是 Guest 内存出现随机 corruption。遇到这类问题，现场表现通常是虚拟机内存 CRC 校验失败或者应用段错误，非常难查。我的习惯是先把 notifier 的 tracepoint 打开，确认触发时机是否和页表操作对齐。

4.3 场景三：KSM 合并后的同页共享

KSM 定期扫描匿名页，把内容完全相同的页合并成一个只读共享页。合并过程中，内核会修改多个进程的 PTE，让它们指向同一个物理页。这个修改动作如果是“映射消失再重新建立”，对 KVM 来说没有问题，走 invalidate 路径即可。但 KSM 为了性能考虑尽量走变更 PTE 的路径，这会触发 change_pte 回调。

KVM 在 change_pte 回调里直接更新 SPTE，把 Guest 映射切换到合并页。如果没有这个回调，KVM 的 SPTE 会一直指向旧页，Guest 通过旧页访问数据，虽然短期内数据内容一致看不出问题，但一旦写时复制触发，Guest 和宿主机的映射关系就会脱节。KSM 和 KVM 在这种场景下是典型的双向依赖：KVM 依赖 KSM 的 rmap 遍历来感知页表变化，KSM 依赖 KVM 快速更新 SPTE 来避免过高的同步开销。

4.4 场景四：Balloon 收缩，QEMU 重新使用还回来的内存

Balloon 收缩时，Guest 告诉 QEMU 某段 GPA 可以重新使用了，QEMU 会重新 mmap 或者对这段 hva 做 madvise(MADV_WILLNEED)。这个过程中宿主机的页表重新建立了映射，KVM 的 EPT 中原本已经没有对应 SPTE。如果之前膨胀时 EPT 没有被正确拆除，收缩后就会出现新旧映射并存的问题，Light VM 场景下很容易演变成内存踩踏。

这个例子说明一个原则：mmu_notifier 不只是“拆”的机制，它关系着整个地址空间映射生命周期的一致性。KVM 在建立 EPT 的时候会检查 hva 当前是否有效，但这里的检查依赖于宿主机页表处于一致的状态，而一致性就是由 notifier 机制保证的。

5. 排查问题的工具和实验方法

5.1 用 ftrace 直接抓 notifier 回调

内核自带 mmu_notifier 相关的 tracepoint，排查问题时第一件事就是把它们打开：

bash复制echo 1 > /sys/kernel/tracing/events/mmu_notifier/mmu_notifier_invalidate_range_start/enable
echo 1 > /sys/kernel/tracing/events/mmu_notifier/mmu_notifier_invalidate_range_end/enable
echo 1 > /sys/kernel/tracing/events/mmu_notifier/mmu_notifier_change_pte/enable
echo 1 > /sys/kernel/tracing/events/mmu_notifier/mmu_notifier_register/enable
# 触发之后
cat /sys/kernel/tracing/trace

输出里你会看到每次回调的进程名、hva 范围、event 类型。这里有两个提示。第一，trace 量可能非常大，虚拟机密集操作内存时每秒上万条是常态，建议先按 QEMU 进程 PID 过滤再分析；第二，trace 捕获的是事件发出的时间点，不是 KVM 处理完成的时间点，要确认 KVM 内部是否处理完，还需要在 KVM 侧加更细的观测点。

5.2 在 KVM 回调里加 trace_printk 做细粒度验证

如果确认事件已经发出，但 KVM 行为不符合预期，那就需要在 KVM 侧加观测点。直接在 kvm_mmu_notifier_invalidate_range_start 这类函数里加 trace_printk 重新编译内核是最稳的办法，它比 kprobe 灵活的地方在于你可以打印 kvm 内部的参数，比如换算后的 gfn、命中的 memslot、持有的锁状态。

实际调试中我通常会在函数入口打印 range 和 event，在获取 kvm->mmu_lock 之后打印 gfn 范围和准备拆除的 SPTE 数量，在函数出口打印是否触发了 remote TLB flush。加完 trace_printk 重新编译内核并不像想象中那么耗时，如果你本来就在开发内核模块，这是家常便饭。注意 trace_printk 不要长期开启，它在热路径上的开销在极端场景下会导致 CPU 软锁。

5.3 构造最小复现场景对照观察

复现 notifier 相关问题不需要大型集群，一台双路服务器加一个小规格虚拟机就够了。比较有效的复现方式是让 QEMU 进程的页面持续被外部操作，比如写一个 helper 进程对 QEMU 的某段 hva 做 mprotect、madvise、page migration，同时观察 Guest 内的访问是否异常。

另一个思路是在宿主机的 cgroup 上不断触发内存回收，加大清 young 和 invalidate 的触发频率。如果 Guest 内出现性能剧烈抖动或者内存 corruption，而且能稳定复现，那基本可以断定 notifier 回调或者锁处理有缺陷。这种对照实验做起来很快，而且不用改业务代码，很适合作为第一轮排查手段。

6. 从 MMU Notifier 看 KVM 内存虚拟化全景（以及新内核演进）

6.1 三层地址映射是怎么被 notifier 串起来的

KVM 内存虚拟化的完整链条是 HVA-GPA-HPA。QEMU 为用户态进程，它的虚拟地址空间就是 HVA 区间；KVM 通过 memslot 结构维护 HVA 到 GPA 的映射关系；CPU 的 EPT 实现 GPA 到 HPA 的翻译。mmu_notifier 在这里扮演的角色是“宿主任意改动 HVA 页表”和“KVM 修复 GPA-HPA 影子映射”之间的桥梁。

当宿主机页表变化时，notifier 收到一段 HVA 范围的失效通知，KVM 通过 memslot 把 HVA 换算成 gfn，再定位到对应的 SPTE 并操作。所以理解 memslot 的查找逻辑和 notifier 的 hva 到 gfn 换算逻辑，比单纯记回调函数更重要。很多内存热插拔问题，本质上都是 memslot 更新和 notifier 回调之间的时序不一致造成的。

6.2 设备直通场景里多出来的一层观察者

设备直通（VFIO）场景下，硬件设备通过 IOMMU 做 DMA，内核会把用户态页表的物理地址信息同步给 IOMMU 页表。VFIO 同样会注册 mmu_notifier，而且通常还配合 interval notifier 来精确管理 DMA 映射的失效。

于是同一个内存热迁移或者页回收操作，会同时触发 KVM 的 notifier 回调链和 VFIO 的 notifier 回调链。这里最麻烦的问题是顺序：KVM 认为页还可用，但 VFIO 的 DMA 映射已经失效，或者反过来。踩过这个坑之后我的结论是，设计直通方案时必须把 KVM 和 VFIO 的失效窗口当成一个整体去审查，单独看任何一条链都可能漏掉竞态。

6.3 mmu_interval_notifier 和传统 mmu_notifier 怎么选

新版内核为“只关心地址空间某一段区间”的模块提供了 mmu_interval_notifier 接口。传统 mmu_notifier 是监听整个地址空间，所有回调都会收到整个 mm 范围的变化事件，效率低，而且自己还要做区间筛选。interval notifier 允许按区间注册，只在目标区间被触碰时触发，特别适合 RDMA、GPU 驱动这类只关心固定 DMA buffer 的场景。

KVM 本身到目前为止仍然以传统 mmu_notifier 为主，因为 KVM 需要感知整个 guest 地址空间的映射状态，无法通过区间注册来简化。但如果你写的是新的外置内存管理模块，只需要监控一段固定的 DMA 区间，那优先用 mmu_interval_notifier 是更合理的选择，它天然避开了很多锁和范围判断的麻烦。

6.4 我在实际项目中会怎么选

在具体项目里选型的时候，我一般会先画一张“谁在观察、谁在被观察”的图。如果观察者需要感知整个地址空间的存在和销毁，传统 mmu_notifier 无可替代；如果只需要在一个固定区间内跟进映射变化，interval notifier 能把回调路径和锁开销降到最低。没有哪种接口是万能的，关键是搞清楚你的模块和 mm 生命周期绑定到什么程度。

如果在写这类代码前没想清楚块，出来的代码很容易出现两种情况：要么在不需要全量监听的场景里背上了整个地址空间的回调负担，要么在对生命周期敏感的场景里用了区间接口导致漏掉 mm 销毁事件。这个取舍，直接决定后续几个月的维护体验。