x86/kvm/x86.c

510  * Handle a fault on a hardware virtualization (VMX or SVM) instruction.
514  * fault we just panic; during reboot instead the instruction is ignored.
728 		   that instruction re-execution will regenerate lost
2114 	/* Treat an INVD instruction as a NOP and just skip it. */
2133 	pr_warn_once("%s instruction emulated as NOP!\n", insn);
5068 	 * an instruction boundary and will not trigger guest emulation of any
5172 	 * instruction boundary and with no events half-injected.
5383 	 * The API doesn't provide the instruction length for software
7624 /* used for instruction fetching */
8645 	 * instruction. So, if the last instruction, be it emulated or
8647 	 * means that the last instruction is an sti. We should not
8866 	 * Do not retry the unhandleable instruction if it faults on the
8868 	 * retry instruction -> write #PF -> emulation fail -> retry
8869 	 * instruction -> ...
8874 	 * If the instruction failed on the error pfn, it can not be fixed,
8885 	 * guest to let the CPU re-execute the instruction in the hope that the
8886 	 * CPU can cleanly execute the instruction that KVM failed to emulate.
8892 	 * If the failed instruction faulted on an access to page tables that
8893 	 * are used to translate any part of the instruction, KVM can't resolve
8895 	 * result in the instruction taking a !PRESENT page fault and thus put
8915 	 * writing instruction, it means the VM-EXIT is caused by shadow
8917 	 * instruction directly.
8919 	 * Note: if the guest uses a non-page-table modifying instruction
8920 	 * on the PDE that points to the instruction, then we will unmap
8921 	 * the instruction and go to an infinite loop. So, we cache the
9001 	 * processor will not generate this exception after the instruction
9035 	 * the instruction has passed all exception checks, and all intercepted
9042 	 * the instruction being emulated.  The intent of forced emulation is
9043 	 * to behave as if KVM intercepted the instruction without an exception
9117  * Decode an instruction for emulation.  The caller is responsible for handling
10212 	char instruction[3];
10226 	static_call(kvm_x86_patch_hypercall)(vcpu, instruction);
10228 	return emulator_write_emulated(ctxt, rip, instruction, 3,
10319  * Note, this is not guaranteed to be invoked on a guest instruction boundary,
10321  * be able to inject exceptions in the "middle" of an instruction, and so must
10322  * also be able to re-inject NMIs and IRQs in the middle of an instruction.
10323  * I.e. for exceptions and re-injected events, NOT invoking this on instruction
10328  * instruction boundaries for asynchronous events.  However, because VM-Exits
10329  * that can occur during instruction execution typically result in KVM skipping
10330  * the instruction or injecting an exception, e.g. instruction and exception
10332  * interrupts, KVM still honors instruction boundaries in most scenarios.
10334  * But, if a VM-Exit occurs during instruction execution, and KVM does NOT skip
10335  * the instruction or inject an exception, then KVM can incorrecty inject a new
10337  * instruction (in the guest).  E.g. if a page fault (#PF, #NPF, EPT violation)
10339  * injected on the restarted instruction instead of being deferred until the
10340  * instruction completes.
10345  * phase of instruction execution, e.g. on the instruction fetch from memory.
10347  * ordering between that side effect, the instruction completing, _and_ the
10383 	 * priority, they're only generated (pended) during instruction
10384 	 * execution, and interrupts are recognized at instruction boundaries.
10386 	 * *previous* instruction and must be serviced prior to recognizing any
10387 	 * new events in order to fully complete the previous instruction.
11119 	 * An instruction is required after local_irq_enable() to fully unblock
11255 		 * of instruction emulation, the rest of the emulation could
11257 		 * this point can start executing an instruction.
11506 		 * instruction emulation. Registers state needs to be copied
13429 		 * another process.  When the instruction that triggered a page
13672 	 * while handling a VMX instruction KVM could've handled the request