x86/kvm/x86.c

246 	STATS_DESC_COUNTER(VM, mmu_shadow_zapped),
247 	STATS_DESC_COUNTER(VM, mmu_pte_write),
248 	STATS_DESC_COUNTER(VM, mmu_pde_zapped),
249 	STATS_DESC_COUNTER(VM, mmu_flooded),
250 	STATS_DESC_COUNTER(VM, mmu_recycled),
251 	STATS_DESC_COUNTER(VM, mmu_cache_miss),
252 	STATS_DESC_ICOUNTER(VM, mmu_unsync),
253 	STATS_DESC_ICOUNTER(VM, pages_4k),
254 	STATS_DESC_ICOUNTER(VM, pages_2m),
255 	STATS_DESC_ICOUNTER(VM, pages_1g),
256 	STATS_DESC_ICOUNTER(VM, nx_lpage_splits),
257 	STATS_DESC_PCOUNTER(VM, max_mmu_rmap_size),
258 	STATS_DESC_PCOUNTER(VM, max_mmu_page_hash_collisions)
657 	 * morph it to a VM-Exit if L1 wants to intercept the exception.  A
673 			 * On VM-Entry, an exception can be pending if and only
784 	 * Async #PF in L2 is always forwarded to L1 as a VM-Exit regardless of
2154  * i.e. the sending of IPI, sending IPI early in the VM-Exit flow reduces
3663  * prior before nested VM-Enter/VM-Exit.
3822 		 * refresh will bug the VM if called after the vCPU has run.
5073 	 * The vCPU can be marked preempted if and only if the VM-Exit was on
5077 	 * preempted if and only if the VM-Exit was due to a host interrupt.
5364 	 * In that case, ignore the VM-Exiting exception as it's an extension
5377 	 * intercepts #PF, ditto for DR6 and #DBs.  If the per-VM capability,
5478 	 * morph the exception to a VM-Exit if appropriate.  Do this only for
5482 	 * pending exception, which in turn may cause a spurious VM-Exit.
6477 	 * on all VM-Exits, thus we only need to kick running vCPUs to force a
6478 	 * VM-Exit.
8890 	 * writing instruction, it means the VM-EXIT is caused by shadow
10248 	 * is injected as intercepted #PF VM-Exits for AMD's Paged Real Mode do
10266  * injected as part of a previous VM-Enter, but weren't successfully delivered
10278  * instruction boundaries for asynchronous events.  However, because VM-Exits
10284  * But, if a VM-Exit occurs during instruction execution, and KVM does NOT skip
10307 	 * Process nested events first, as nested VM-Exit supersedes event
10309 	 * be saved into the appropriate vmc{b,s}12 fields on nested VM-Exit.
10349 	 * Exceptions that morph to VM-Exits are handled above, and pending
10350 	 * exceptions on top of injected exceptions that do not VM-Exit should
10358 	 * nested VM-Enter or event re-injection so that a different pending
10361 	 * Otherwise, continue processing events even if VM-Exit occurred.  The
10362 	 * VM-Exit will have cleared exceptions that were meant for L2, but
10369 	 * A pending exception VM-Exit should either result in nested VM-Exit
10371 	 * VM-Exits cannot be injected (flag should _never_ be set).
10485 	 * infinite loop as KVM will bail from VM-Enter to inject the pending
10542 /* Return total number of NMIs pending injection to the VM */
11000 		 * Assert that vCPU vs. VM APICv state is consistent.  An APICv
11002 		 * per-VM state, and responding vCPUs must wait for the update
11020 		/* Note, VM-Exits that go down the "slow" path are accounted below. */
11068 	 * VM-Exit on SVM and any ticks that occur between VM-Exit and now.
11159 	 * state field (AMD does not have a similar field and a VM-Exit always
11324 	/* Exclude PKRU, it's restored separately immediately after VM-Exit. */
11404 	 * a pending VM-Exit if L1 wants to intercept the exception.
12248 	 * SVM doesn't unconditionally VM-Exit on INIT and SHUTDOWN, thus it's
12477 			 * booting a VM while issuing an S4 host suspend....
12622  * @kvm: the kvm pointer to the VM.
12636  * remain valid and unchanged until the VM is destroyed, i.e., the
12867 	 * trackers attached to the VM, i.e. if KVMGT is in use.