Volume 3B System Programming Guide_ Part 2 (794104), страница 44
Текст из файла (страница 44)
3 22-27VM ENTRIES22.7VM-ENTRY FAILURES DURING OR AFTER LOADINGGUEST STATEVM-entry failures due to the checks identified in Section 22.3.1 and failures duringthe MSR loading identified in Section 22.4 are treated differently from those thatoccur earlier in VM entry.
In these cases, the following steps take place:1. Information about the VM-entry failure is recorded in the VM-exit informationfields:— Exit reason.•Bits 15:0 of this field contain the basic exit reason. It is loaded with anumber indicating the general cause of the VM-entry failure. Thefollowing numbers are used:33.VM-entry failure due to invalid guest state. A VM entry failed one ofthe checks identified in Section 22.3.1.34.VM-entry failure due to MSR loading. A VM entry failed in an attemptto load MSRs (see Section 22.4).41.VM-entry failure due to machine check. A machine check occurredduring VM entry (see Section 22.8).••Bit 31 is set to 1 to indicate a VM-entry failure.The remainder of the field (bits 30:16) is cleared.— Exit qualification. This field is set based on the exit reason.•VM-entry failure due to invalid guest state.
In most cases, the exit qualification is cleared to 0. The following non-zero values are used in thecases indicated:1. Not used.2. Failure was due to a problem loading the PDPTRs (see Section22.3.1.6).3. Failure was due to an attempt to inject a non-maskable interrupt(NMI) into a guest that is blocking events through the STI blocking bitin the interruptibility-state field. Such failures are implementationspecific (see Section 22.3.1.5).4.Failure was due to an invalid VMCS link pointer (see Section 22.3.1.5).VM-entry checks on guest-state fields may be performed in any order.Thus, an indication by exit qualification of one cause does not imply thatthere are not also other errors.
Different processors may give differentexit qualifications for the same VMCS.•VM-entry failure due to MSR loading. The exit qualification is loaded toindicate which entry in the VM-entry MSR-load area caused the problem(1 for the first entry, 2 for the second, etc.).— All other VM-exit information fields are unmodified.22-28 Vol. 3VM ENTRIES2.
Processor state is loaded as would be done on a VM exit (see Section 23.5). Ifthis results in [CR4.PAE & CR0.PG & ~IA32_EFER.LMA] = 1, page-directorypointers (PDPTRS) may be checked and loaded (see Section 23.5.4).3. The state of blocking by NMI is what it was before VM entry.4. MSRs are loaded as specified in the VM-exit MSR-load area (see Section 23.6).Although this process resembles that of a VM exit, many steps taken during a VM exitdo not occur for these VM-entry failures:••••Most VM-exit information fields are not updated (see step 1 above).The valid bit in the VM-entry interruption-information field is not cleared.The guest-state area is not modified.No MSRs are saved into the VM-exit MSR-store area.22.8MACHINE CHECKS DURING VM ENTRYIf a machine check occurs during a VM entry, one of the following occurs:•The machine check is handled normally.
If CR4.MCE = 1, a machine-checkexception (#MC) is delivered through the IDT. If CR4.MCE = 0, the processorgoes to the shutdown state.•A VM-entry failure occurs as described in Section 22.7. The basic exit reason is41, for “VM-entry failure due to machine check.”The first option is not used if the machine check occurs after any guest state hasbeen loaded.Vol. 3 22-29VM ENTRIES22-30 Vol. 3CHAPTER 23VM EXITSVM exits occur in response to certain instructions and events in VMX non-root operation.
Section 21.1 through Section 21.3 detail the causes of VM exits. VM exitsperform the following operation:1. Information about the cause of the VM exit is recorded in the VM-exit informationfields and the valid bit (bit 31) is cleared in the VM-entry interruption-informationfield (Section 23.2).2. Processor state is saved in the guest-state area (Section 23.3).3. MSRs may be saved in the VM-exit MSR-store area (Section 23.4).4. The following may be performed in parallel and in any order (Section 23.5):— Processor state is loaded based in part on the host-state area and someVM-exit controls.
This step is not performed for SMM VM exits that activatethe dual-monitor treatment of SMIs and SMM. See Section 24.16.6 forinformation on how processor state is loaded by such VM exits.— Address-range monitoring is cleared.5. MSRs may be loaded from the VM-exit MSR-load area (Section 23.6). This step isnot performed for SMM VM exits that activate the dual-monitor treatment ofSMIs and SMM.VM exits are not logged with last-branch records, do not produce branch-tracemessages, and do not update the branch-trace store.Section 23.1 clarifies the nature of the architectural state before a VM exit begins.The steps described above are detailed in Section 23.2 through Section 23.6.Section 24.16 describes the dual-monitor treatment of system-management interrupts (SMIs) and system-management mode (SMM).
Under this treatment, ordinarytransitions to SMM are replaced by VM exits to a separate SMM monitor. Called SMMVM exits, these are caused by the arrival of an SMI or the execution of VMCALL inVMX root operation. SMM VM exits differ from other VM exits in ways that aredetailed in Section 24.16.2.23.1ARCHITECTURAL STATE BEFORE A VM EXITThis section describes the architectural state that exists before a VM exit, especiallyfor VM exits caused by events that would normally be delivered through the IDT.Note the following:•An exception causes a VM exit directly if the bit corresponding to that exceptionis set in the exception bitmap. A non-maskable interrupt (NMI) causes a VM exitVol. 3 23-1VM EXITSdirectly if the “NMI exiting” VM-execution control is 1.
An external interruptcauses a VM exit directly if the “external-interrupt exiting” VM-execution controlis 1. A start-up IPI (SIPI) that arrives while a logical processor is in the wait-forSIPI activity state causes a VM exit directly. INIT signals that arrive while theprocessor is not in the wait-for-SIPI activity state cause VM exits directly.•An exception, NMI, external interrupt, or software interrupt causes a VM exitindirectly if it does not do so directly but delivery of the event causes a nestedexception, double fault, task switch, or APIC access (see Section 21.2) thatcauses a VM exit.•An event results in a VM exit if it causes a VM exit (directly or indirectly).The following bullets detail when architectural state is and is not updated in responseto VM exits:•If an event causes a VM exit directly, it does not update architectural state as itwould have if it had it not caused the VM exit:— A debug exception does not update DR6, DR7.GD, or IA32_DEBUGCTL.LBR.(Information about the nature of the debug exception is saved in the exitqualification field.)— A page fault does not update CR2.
(The linear address causing the page faultis saved in the exit-qualification field.)— An NMI causes subsequent NMIs to be blocked, but only after the VM exitcompletes.— An external interrupt does not acknowledge the interrupt controller and theinterrupt remains pending, unless the “acknowledge interrupt on exit”VM-exit control is 1. In such a case, the interrupt controller is acknowledgedand the interrupt is no longer pending.— The flags L0 – L3 in DR7 (bit 0, bit 2, bit 4, and bit 6) are not cleared when atask switch causes a VM exit.— If a task switch causes a VM exit, none of the following are modified by thetask switch: old task-state segment (TSS); new TSS; old TSS descriptor; newTSS descriptor; RFLAGS.NT1; or the TR register.— No last-exception record is made if the event that would do so directly causesa VM exit.— If a machine-check exception causes a VM exit directly, this does not preventmachine-check MSRs from being updated.
These are updated by the machinecheck itself and not the resulting machine-check exception.1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because mostprocessors that support VMX operation also support Intel 64 architecture. For processors that donot support Intel 64 architecture, this notation refers to the 32-bit forms of those registers(EAX, EIP, ESP, EFLAGS, etc.). In a few places, notation such as EAX is used to refer specifically tolower 32 bits of the indicated register.23-2 Vol. 3VM EXITS— If the logical processor happens to be in an inactive state (see Section20.4.2) and not executing instructions, some events may be blocked butothers may return the logical processor to the active state.
Unblocked eventsmay cause VM exits.1 If an unblocked event causes a VM exit directly, areturn to the active state occurs only after the VM exit completes.2 TheVM exit generates any special bus cycle that is normally generated when theactive state is entered from that activity state.•If an event causes a VM exit indirectly, the event does update architectural state:— A debug exception updates DR6, DR7, and the IA32_DEBUGCTL MSR.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
