在AMD平台上实现KVM虚拟化技术 (20)

yesxx

内存虚拟化(2)

5. 为了维护客操作系统页表和 Shadow 页表的一致性，KVM 实现上采取了一些技巧 :

a. 在第一次建立 gva 到 hpa 的映射时，KVM 需要将该hpa 标记为只读的， 以便于下一次该页被写时，KVM 能将CPU TLB 及 Shadow 页表的 “dirty”标记同步到客操作系统对应的页表项上linux。

b. 在 shadow 页表上建立 gva 到 hpa 的映射时，如果该gva 对应的是客操作系统上的页表页， 则 KVM 将该hpa 映射为只读的。 这样做的目的是能随时控制客操作系统对其页表的修改，及时将客操作系统页表的变化同步到Shadow 页表上。

c. 为维护客操作系统的页表页和其对应的Shadow 页表页的对应关系， KVM 在描述每个虚拟机物理内存区域的 struct kvm_memory_slot 中提供了逆向映射信息linux，能将一个客操作系统页表页的 gfn 映射到其所有 Shadow 页表项， 其中对于有多个 Shadow 页表项对应于相同 gfn 的情况， 采用了一个 struct kvm_rmap_desc 数据结构来组织映射关系。

6. 分页模式的客操作系统的每一个进程在 KVM 上都有一个独立的 Shadow 页表，为了避免减低性能，在客操作系统进程切换时，KVM 是不能直接释放以前进程的 Shadow 页表的，即系统中所有的 Shadow 页表页都是缓存的。 为了在虚拟机的 CR3 发生变化后重新使用必要的 Shadow 页表页， KVM 为每一个 Shadow 页表页提供了一个 struct kvm_mmu_page 数据结构，该结构中包含该 Shadow 页表页对应的 gfn。 在每个虚拟机对应的 struct kvm_arch 结构中有一个 hash 表linux，mmu_page_hash[]， 用于按 hash 方式组织虚拟机全部的 Shadow 页表页。 每次发生 CR3 改变或 Shadow 页表的“PageFault”行为时，KVM 以 gfn 为参数，通过查找 hash 表，可确定对应的 Shadow 页表页是否在缓存中存在。

7. 对于那些采用非分页模式的客操作系统 ( 如 Linux 启动阶段的实模式，非分页保护模式 )，KVM 仍然采用 Shadow 页表的分页模式来实现，这是提供统一的物理内存分配所必须的，只不过对于非分页模式的虚拟机而言，免去了客操作系统和 Shadow 页表同步的问题。 当然，KVM 能通过对 CR0 的截取，向客操作系统屏蔽分页机制的存在。详细:http://www.51rhca.com/archives/562