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 shocould be. the guest can't be allowed access to the hardware page tables because then it wowould essential 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
Think about it.
Hypervisor manages GVA-> HPA ing. Guest is unable to control real, and has no control. It can only rely on hypervisor. In fact, page fault will cause VM exit for hypervisor to process.
Notice that this avoids the GVA-> GPA translation step.
Therefore, GVA-> GPA is omitted.
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"
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'tbeen 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
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
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
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
Shadow page tables can be kept fresh.
All in all, GPA --> HPA ing is done by hypervisor, and guest cannot feel it at all. Therefore, it is considered that this is done under shadow.
All GPA --> HPA must be completed by the VM exit for the 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 manages GVA-> HPA ing, without GVA-> GPa, GPA-> HPA ing.
2: page fault generates an address error, which must be handled by the hypervisor by VM exit.
Quick note on shadow page table from:
Http://fleurer-lee.com/2013/05/19/shadow-quick-note.html
The tables
In a system without hardware virtualization support, these tables are involved in memory Virtualization:
- Guest page table: Guest Virtual Address => guest physical address
- Pmap: Guest physical address => host physical address
- Shadow page table: Guest Virtual Address => host physical address
As the infrastructure for memory virtualization, the shadow page table is equivalent to the result of the superposition of the guest page table and pmap, and is finally handed over to the F3. The guest page table will be updated, and pmap will also change. The shadow page table needs to be synchronized with them, but the "incomplete" synchronization is also allowed, the role played by the shadow page table is actually closer to TLB. For example, a ing in the guest page table does not exist in the shadow page table. This is allowed. when accessing the memory corresponding to this ing, a page error occurs and the vmm can capture it, adjust the shadow page table to add this ing. In guest's view, this is only equivalent to TLB miss.
Hardware virtualization alization: the nuts and bolts
From:
Http://www.anandtech.com/show/2480