kvm/x86/mmu.rst

8 for presenting a standard x86 mmu to the guest, while translating guest
14 	       the guest should not be able to determine that it is running
19 	       the guest must not be able to touch host memory not assigned
28                Linux memory management code must be in control of guest memory
32                report writes to guest memory to enable live migration
47 gfn   guest frame number
48 gpa   guest physical address
49 gva   guest virtual address
50 ngpa  nested guest physical address
51 ngva  nested guest virtual address
54 gpte  guest pte (referring to gfns)
63 of the current paging mode and cr3 during guest entry, as well as
73 addresses for the guest.  Different translations are required at different
76 - when guest paging is disabled, we translate guest physical addresses to
78 - when guest paging is enabled, we translate guest virtual addresses, to
79   guest physical addresses, to host physical addresses (gva->gpa->hpa)
80 - when the guest launches a guest of its own, we translate nested guest
81   virtual addresses, to nested guest physical addresses, to guest physical
92 Guest memory (gpa) is part of the user address space of the process that is
93 using kvm.  Userspace defines the translation between guest addresses and user
104 The mmu is driven by events, some from the guest, some from the host.
106 Guest generated events:
131 Leaf ptes point at guest pages.
147   (*) the guest hypervisor will encode the ngva->gpa translation into its page
156     Examples include real mode translation, large guest pages backed by small
161     If clear, this page corresponds to a guest page table denoted by the gfn
164     When role.has_4_byte_gpte=1, the guest uses 32-bit gptes while the host uses 64-bit
165     sptes.  That means a guest page table contains more ptes than the host,
166     so multiple shadow pages are needed to shadow one guest page.
168     first or second 512-gpte block in the guest page table.  For second-level
170     (since each first-level guest page is shadowed by two first-level
174     Inherited guest access permissions from the parent ptes in the form uwx.
181     Reflects the size of the guest PTE for which the page is valid, i.e. '0'
206     Indicates the shadow page is created for a nested guest.
208     The page is not backed by a guest page table, but its first entry
217     guest. The MMU generation is only ever '0' or '1'. Note, the TDP MMU doesn't
222     Either the guest page table containing the translations shadowed by this
229     sptes in spt point either at guest pages, or at lower-level shadow pages.
233     guest pages as leaves.
259     If true, then the translations in this page may not match the guest's
262     are synchronized when the guest executes invlpg or flushes its tlb by
277     A guest may write to a page table many times, causing a lot of
299 The guest uses two events to synchronize its tlb and page tables: tlb flushes
303 guest's cr3.  This is expensive, so we keep all guest page tables write
306 A special case is when a guest page table is reachable from the current
307 guest cr3.  In this case, the guest is obliged to issue an invlpg instruction
309 protection from the guest page, and allowing the guest to modify it freely.
310 We synchronize modified gptes when the guest invokes invlpg.  This reduces
311 the amount of emulation we have to do when the guest modifies multiple gptes,
312 or when the a guest page is no longer used as a page table and is used for
313 random guest data.
322 - guest page fault (or npt page fault, or ept violation)
326   - a true guest fault (the guest translation won't allow the access) (*)
337  - if the RSV bit of the error code is set, the page fault is caused by guest
350  - if needed, walk the guest page tables to determine the guest translation
353    - if permissions are insufficient, reflect the fault back to the guest
368    - if successful, we can let the guest continue and modify the gpte
372    - if failed, unshadow the page and let the guest continue
380     guest will use it in the near future
382 Guest control register updates:
405 works for the guest kernel, not guest userspace.  When the guest
406 cr0.wp=1, this does not present a problem.  However when the guest cr0.wp=0,
408 semantics require allowing any guest kernel access plus user read access).
431   directly inject #PF to guest due to failed permission check.
445 The mmu supports all combinations of large and small guest and host pages.
447 two separate 2M pages, on both guest and host, since the mmu always uses PAE
453 - the guest pte must be a large pte of at least equivalent size (if tdp is
454   enabled, there is no guest pte and this condition is satisfied)
457 - the guest page must be wholly contained by a single memory slot
476 kvm_memslots(kvm)->generation, and increased whenever guest memory info