Volume 3B System Programming Guide_ Part 2 (794104), страница 43
Текст из файла (страница 43)
If the “NMI exiting”control is 1, such blocking remains in effect as long as the logical processor isin VMX non-root operation.— The following items describe the use of bit 3 (blocking by NMI) in the interruptibility-state field if the “virtual NMIs” VM-execution control is 1:••The bit’s value does not affect the blocking of NMIs after VM entry. NMIsare not blocked in VMX non-root operation (except for ordinary blockingfor other reasons, such as by the MOV SS instruction, the wait-for-SIPIstate, etc.)•The bit’s value determines whether there is virtual-NMI blocking afterVM entry.
If the bit is 1, virtual-NMI blocking is in effect after VM entry. Ifthe bit is 0, there is no virtual-NMI blocking after VM entry unless theVM entry is injecting an NMI (see Section 22.5.1).Blocking of system-management interrupts (SMIs) is determined as follows:— If the VM entry was not executed in system-management mode (SMM), SMIblocking is unchanged by VM entry.— If the VM entry was executed in SMM, SMIs are blocked after VM entry if andonly if the bit 2 in the interruptibility-state field is 1.22.6.2Activity StateThe activity-state field in the guest-state area controls whether, after VM entry, thelogical processor is active or in one of the inactive states identified in Section 20.4.2.The use of this field is determined as follows:•If the VM entry is injecting, the logical processor is in the active state afterVM entry.
While the consistency checks described in Section 22.3.1.5 on theactivity-state field do apply in this case, the contents of the activity-state field donot determine the activity state after VM entry.•If the VM entry is not injecting, the logical processor ends VM entry in the activitystate specified in the guest-state area. If VM entry ends with the logicalprocessor in an inactive activity state, the VM entry generates any special buscycle that is normally generated when that activity state is entered from theactive state.•Some activity states unconditionally block certain events.
The following blockingis in effect after any VM entry that puts the processor in the indicated state:— The active state blocks start-up IPIs (SIPIs). SIPIs that arrive while a logicalprocessor is in the active state and in VMX non-root operation are discardedand do not cause VM exits.22-24 Vol. 3VM ENTRIES— The HLT state blocks start-up IPIs (SIPIs). SIPIs that arrive while a logicalprocessor is in the HLT state and in VMX non-root operation are discarded anddo not cause VM exits.— The shutdown state blocks external interrupts and SIPIs. External interruptsthat arrive while a logical processor is in the shutdown state and in VMX nonroot operation do not cause VM exits even if the “external-interrupt exiting”VM-execution control is 1.
SIPIs that arrive while a logical processor is in theshutdown state and in VMX non-root operation are discarded and do notcause VM exits.— The wait-for-SIPI state blocks external interrupts, non-maskable interrupts(NMIs), INIT signals, and system-management interrupts (SMIs). Suchevents do not cause VM exits if they arrive while a logical processor is in thewait-for-SIPI state and in VMX non-root operation do not cause VM exitsregardless of the settings of the pin-based VM-execution controls.22.6.3Delivery of Pending Debug Exceptions after VM EntryThe pending debug exceptions field in the guest-state area indicates whether thereare debug exceptions that have not yet been delivered (see Section 20.4.2).
Thissection describes how these are treated on VM entry.There are no pending debug exceptions after VM entry if any of the following aretrue:•The VM entry is injecting with one of the following interruption types: externalinterrupt, non-maskable interrupt (NMI), hardware exception, or privilegedsoftware exception.•The interruptibility-state field does not indicate blocking by MOV SS and theVM entry is injecting with either of the following interruption type: softwareinterrupt or software exception.•The VM entry is not injecting and the activity-state field indicates eithershutdown or wait-for-SIPI.If none of the above hold, the pending debug exceptions field specifies the debugexceptions that are pending for the guest. There are valid pending debug exceptions if either the BS bit (bit 14) or the enable-breakpoint bit (bit 12) is 1.
If thereare valid pending debug exceptions, they are handled as follows:•If the VM entry is not injecting, the pending debug exceptions are treated as theywould had they been encountered normally in guest execution:— If the logical processor is not blocking such exceptions (the interruptibilitystate field indicates no blocking by MOV SS), a debug exception is deliveredafter VM entry (see below).— If the logical processor is blocking such exceptions (due to blocking byMOV SS), the pending debug exceptions are held pending or lost as wouldnormally be the case.Vol. 3 22-25VM ENTRIES•If the VM entry is injecting (with interruption type software interrupt or softwareexception and with blocking by MOV SS), the following items apply:— For injection of a software interrupt or of a software exception with vector 3(#BP) or vector 4 (#OF), the pending debug exceptions are treated as theywould had they been encountered normally in guest execution if the corresponding instruction (INT3 or INTO) were executed after a MOV SS thatencountered a debug trap.— For injection of a software exception with a vector other than 3 and 4, thepending debug exceptions may be lost or they may be delivered afterinjection (see below).If there are no valid pending debug exceptions (as defined above), no pending debugexceptions are delivered after VM entry.If a pending debug exception is delivered after VM entry, it has the priority of “trapson the previous instruction” (see Section 5.9 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A).
Thus, INIT signals and systemmanagement interrupts (SMIs) take priority of such an exception, as do VM exitsinduced by the TPR shadow (see Section 22.6.6). The exception takes priority overany pending non-maskable interrupt (NMI) or external interrupt and also overVM exits due to the 1-settings of the “interrupt-window exiting” and “NMI-windowexiting” VM-execution controls.A pending debug exception delivered after VM entry causes a VM exit if the bit 1(#DB) is 1 in the exception bitmap.
If it does not cause a VM exit, it updates DR6normally.22.6.4Interrupt-Window ExitingThe “interrupt-window exiting” VM-execution control may cause a VM exit to occurimmediately after VM entry (see Section 21.3 for details).The following items detail the treatment of these VM exits:••These VM exits follow event injection if such injection is specified for VM entry.•VM exits caused by this control wake the logical processor if it just entered theHLT state because of a VM entry (see Section 22.6.2).
They do not occur if thelogical processor just entered the shutdown state or the wait-for-SIPI state.Non-maskable interrupts (NMIs) and higher priority events take priority overVM exits caused by this control. VM exits caused by this control take priority overexternal interrupts and lower priority events.22.6.5NMI-Window ExitingThe “NMI-window exiting” VM-execution control may cause a VM exit to occur immediately after VM entry (see Section 21.3 for details).22-26 Vol.
3VM ENTRIESThe following items detail the treatment of these VM exits:••These VM exits follow event injection if such injection is specified for VM entry.•VM exits caused by this control wake the logical processor if it just entered eitherthe HLT state or the shutdown state because of a VM entry (see Section 22.6.2).They do not occur if the logical processor just entered the wait-for-SIPI state.Debug-trap exceptions and higher priority events take priority over VM exitscaused by this control.
VM exits caused by this control take priority over nonmaskable interrupts (NMIs) and lower priority events.22.6.6VM Exits Induced by the TPR ShadowIf the “use TPR shadow” and “virtualize APIC accesses” VM-execution controls areboth 1, a VM exit occurs immediately after VM entry if the value of bits 3:0 of the TPRthreshold VM-execution control field is greater than the value of bits 7:4 in byte 128on the virtual-APIC page (see Section 20.6.8).The following items detail the treatment of these VM exits:•The VM exits are not blocked if RFLAGS.IF = 0 or by the setting of bits in theinterruptibility-state field in guest-state area.••The VM exits follow event injection if such injection is specified for VM entry.•These VM exits wake the logical processor if it just entered the HLT state as partof a VM entry (see Section 22.6.2). They do not occur if the logical processor justentered the shutdown state or the wait-for-SIPI state.The VM exits have the same priority as the “trap on task switch” event (seeSection 5.9, “Priority Among Simultaneous Exceptions and Interrupts,” in theIntel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A).They thus have priority over those described in Section 22.6.4 and Section 22.6.5as well as any interrupts that may be pending at the time of VM entry.If such a VM exit is suppressed because the processor just entered theshutdown state, it occurs after the delivery of any event that cause the logicalprocessor to leave the shutdown state while remaining in VMX non-rootoperation (e.g., due to an NMI that occurs while the “NMI-exiting” VM-executioncontrol is 0).•The basic exit reason is “TPR below threshold.”22.6.7VM Entries and Advanced Debugging FeaturesVM entries are not logged with last-branch records, do not produce branch-tracemessages, and do not update the branch-trace store.Vol.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
