Lines Matching refs:guest
5 for presenting a standard x86 mmu to the guest, while translating guest
10 - correctness: the guest should not be able to determine that it is running
14 - security: the guest must not be able to touch host memory not assigned
19 - integration: Linux memory management code must be in control of guest memory
22 - dirty tracking: report writes to guest memory to enable live migration
34 gfn guest frame number
35 gpa guest physical address
36 gva guest virtual address
37 ngpa nested guest physical address
38 ngva nested guest virtual address
41 gpte guest pte (referring to gfns)
49 of the current paging mode and cr3 during guest entry, as well as
59 addresses for the guest. Different translations are required at different
62 - when guest paging is disabled, we translate guest physical addresses to
64 - when guest paging is enabled, we translate guest virtual addresses, to
65 guest physical addresses, to host physical addresses (gva->gpa->hpa)
66 - when the guest launches a guest of its own, we translate nested guest
67 virtual addresses, to nested guest physical addresses, to guest physical
79 using kvm. Userspace defines the translation between guest addresses and user
90 The mmu is driven by events, some from the guest, some from the host.
115 Leaf ptes point at guest pages.
128 (*) the guest hypervisor will encode the ngva->gpa translation into its page
137 Examples include real mode translation, large guest pages backed by small
142 If clear, this page corresponds to a guest page table denoted by the gfn
145 When role.cr4_pae=0, the guest uses 32-bit gptes while the host uses 64-bit
146 sptes. That means a guest page table contains more ptes than the host,
147 so multiple shadow pages are needed to shadow one guest page.
149 first or second 512-gpte block in the guest page table. For second-level
151 (since each first-level guest page is shadowed by two first-level
155 Inherited guest access permissions in the form uwx. Note execute
183 Either the guest page table containing the translations shadowed by this
190 sptes in spt point either at guest pages, or at lower-level shadow pages.
194 guest pages as leaves.
196 An array of 512 guest frame numbers, one for each present pte. Used to
201 A counter keeping track of how many hardware registers (guest cr3 or
211 If true, then the translations in this page may not match the guest's
214 are synchronized when the guest executes invlpg or flushes its tlb by
233 A guest may write to a page table many times, causing a lot of
251 The guest uses two events to synchronize its tlb and page tables: tlb flushes
255 guest's cr3. This is expensive, so we keep all guest page tables write
258 A special case is when a guest page table is reachable from the current
259 guest cr3. In this case, the guest is obliged to issue an invlpg instruction
261 protection from the guest page, and allowing the guest to modify it freely.
262 We synchronize modified gptes when the guest invokes invlpg. This reduces
263 the amount of emulation we have to do when the guest modifies multiple gptes,
264 or when the a guest page is no longer used as a page table and is used for
265 random guest data.
274 - guest page fault (or npt page fault, or ept violation)
278 - a true guest fault (the guest translation won't allow the access) (*)
289 - if the RSV bit of the error code is set, the page fault is caused by guest
299 - if needed, walk the guest page tables to determine the guest translation
301 - if permissions are insufficient, reflect the fault back to the guest
310 - if successful, we can let the guest continue and modify the gpte
312 - if failed, unshadow the page and let the guest continue
319 guest will use it in the near future
342 works for the guest kernel, not guest guest userspace. When the guest
343 cr0.wp=1, this does not present a problem. However when the guest cr0.wp=0,
345 semantics require allowing any guest kernel access plus user read access).
367 directly inject #PF to guest due to failed permission check.
381 The mmu supports all combinations of large and small guest and host pages.
383 two separate 2M pages, on both guest and host, since the mmu always uses PAE
389 - the guest pte must be a large pte of at least equivalent size (if tdp is
390 enabled, there is no guest pte and this condition is satisfied)
393 - the guest page must be wholly contained by a single memory slot
433 kvm_memslots(kvm)->generation, and increased whenever guest memory info