3.5 设备页面迁移：migrate_vma 三阶段操作协议⭐

在 Device Private Entry 之后，我们继续看“页面怎么真正从 CPU 内存搬到设备内存，或者从设备内存搬回 CPU 内存”。本篇是migrate_vma的总览：先讲清楚它为什么被设计成一套分段协议、核心工作单struct migrate_vma长什么样，以及三阶段／五段模型的整体骨架。源码级的逐段走读拆到两篇下篇：《3.5.1 阶段详解：setup、pages、finalize 源码走读》聚焦 core MM 的实现，《3.5.2 实战与并发：双向流程、锁协议与 migrate_device》聚焦驱动视角的完整流程与并发边界。前几篇已经把 HMM 设备内存迁移的几块基础拼起来了：ZONE_DEVICE让设备 PFN 拥有struct page，dev_pagemap描述设备页背后的控制面，Device Private Entry 把“页面驻留在设备私有内存”编码进 CPU 页表。但还剩一个关键问题：这些状态是谁制造出来的？设备驱动不能简单地把 CPU PTE 改成 device private entry，然后自己拷贝数据。原因很直接：用户线程、其他 CPU、GUP、fork、rmap、LRU、设备页表、MMU notifier 都可能同时参与这个地址范围。页面迁移不是一次普通 memcpy，而是一个并发协议。migrate_vma就是 HMM 给设备驱动提供的这套协议。它把公共 MM 工作和驱动私有工作拆开：