What exactly do shadow page tables (for VMMs) do

Shadow page tables

Shadow page tables are used by the hypervisor to keep track of the state in which the guest "thinks" its page tables should be. The guest can't be allowed access to the hardware page tables because then it would essentially have control of the machine. So, the hypervisor keeps the "real" mappings (guest virtual -> host physical) in the hardware when the relevant guest is executing, and keeps a representation of the page tables that the guest thinks it's using "in the shadows," or at least that's how I like to think about it.

hypervisor 管理了 gva->hpa 的映射。guest 无法控制real CR3，丧失控制权，只能依赖于hypervisor。实际上，page fault 都会导致 vm exit,让hypervisor 处理。

Notice that this avoids the GVA->GPA translation step.

从而省略了GVA->GPA这一步。

As far as page faults go, nothing changes from the hardware's point of view (remember, the hypervisor makes it so the page tables used by the hardware contain GVA->HPA mappings), a page fault will simply generate an exception and redirect to the appropriate exception handler. However, when a page fault occurs while a VM is running, this exception can be "forwarded" to the hypervisor, which can then handle it appropriately.

The hypervisor must build up these shadow page tables as it sees page faults generated by the guest. When the guest writes a mapping into one of its page tables, the hypervisor won't know right away, so the shadow page tables won't instantly "be in sync" with what the guest intends. So the hypervisor will build up the shadow page tables in, e.g., the following way:

• Guest writes a mapping for VA 0xdeadbeef into it's page tables (a location in memory), but remember, this mapping isn't being used by the hardware.
• Guest accesses 0xdeadbeef, which causes a page fault because the real page tables haven't been updated to add the mapping
• Page fault is forwarded to hypervisor
• Hypervisor looks at guest page tables and notices they're different from shadow page tables, says "hey, I haven't created a real mapping for 0xdeadbeef yet"
• So it updates its shadow page tables and creates a corresponding 0xdeadbeef->HPA mapping for the hardware to use.

The previous case is called a shadow page fault because it is caused solely by the introduction of memory virtualization. So the handling of the page fault will stop at the hypervisor and the guest OS will have no idea that it even occurred. Note that the guest can also generate genuine page faults because of mappings it hasn't tried to create yet, and the hypervisor will forward these back up into the guest. 

Also realize that this entire process implies that every page fault that occurs while the guest is executing must cause an exit to the VMM so the shadow page tables can be kept fresh. 

总而言之，GPA-->HPA的映射都是hypervisor在底下完成的，guest根本感觉不到，所以认为这些是shadow下完成的。

所有的 GPA-->HPA都必须 vm exit让hypervisor完成。

This is expensive, and one of the reasons why hardware support was introduced for memory virtualization. (here is one quick intro to nested, or extended page tables)

1: hypervisor 管理 gva -> hpa 的映射，没有 gva->gpa, gpa -> hpa的映射。

2: page fault 产生地址错误，都必须 vm exit 让 hypervisor 处理。

Quick Note on Shadow Page Table  

From:

http://fleurer-lee.com/2013/05/19/shadow-quick-note.html

The Tables

在没有硬件虚拟化支持的系统上，为实现内存的虚拟化，会牵涉到这几张表：

1. Guest 页表: Guest 虚拟地址 => Guest 物理地址
2. pmap: Guest 物理地址 => Host 物理地址
3. 影子页表: Guest 虚拟地址 => Host 物理地址

影子页表作为内存虚拟化的基础设施，大约相当于 Guest 页表与 pmap 叠加的结果，会被最后交给 cr3 。 Guest 页表会更新，pmap 也会变化，影子页表需要想方设法与它们保持同步，但 "不完整" 的同步也是允许的，影子页表扮演的角色实际上也更接近于 TLB 。比方说在 Guest 页表中存在的一项映射在影子页表中不存在， 这是允许的，到访问这条映射对应的内存时，会发生页面错误, VMM能够捕获它，调整影子页表增加这条映射，这在 Guest 看来仅仅相当于 TLB Miss 而已。

Hardware Virtualization: the Nuts and Bolts

From:

http://www.anandtech.com/show/2480