Volume 3B System Programming Guide_ Part 2 (794104), страница 42
Текст из файла (страница 42)
The event is delivered using the vector in that field to select adescriptor in the IDT. Since event injection occurs after loading IDTR from the gueststate area, this is the guest IDT.Section 22.5.1 provides details of event injection. In general, the event is deliveredexactly as it would had it been generated normally.If event delivery encounters a nested exception (for example, a general-protectionexception because the vector indicates a descriptor beyond the IDT limit), the exception bitmap is consulted using the vector of that exception. If the bit is 0, the exception is delivered through the IDT. If the bit is 1, a VM exit occurs. Section 22.5.2details cases in which event injection causes a VM exit.22.5.1Details of Event InjectionThe event-injection process is controlled by the contents of the VM-entry interruptioninformation field (format given in Table 20-11), the VM-entry exception error-codefield, and the VM-entry instruction-length field.
The following items provide details ofthe process:•The value pushed on the stack for RFLAGS is generally that which was loadedfrom the guest-state area. The value pushed for the RF flag is not modified basedon the type of event being delivered. However, the pushed value of RFLAGS maybe modified if a software interrupt is being injected into a guest that will be invirtual-8086 mode (see below). After RFLAGS is pushed on the stack, the valuein the RFLAGS register is modified as is done normally when delivering an eventthrough the IDT.•The instruction pointer that is pushed on the stack depends on the type of eventand whether nested exceptions occur during its delivery. The term current22-20 Vol.
3VM ENTRIESguest RIP refers to the value to be loaded from the guest-state area. The valuepushed is determined as follows:1— If VM entry successfully injects (with no nested exception) an event withinterruption type external interrupt, NMI, or hardware exception, the currentguest RIP is pushed on the stack.— If VM entry successfully injects (with no nested exception) an event withinterruption type software interrupt, privileged software exception, orsoftware exception, the current guest RIP is incremented by the VM-entryinstruction length before being pushed on the stack.— If VM entry encounters an exception while injecting an event and thatexception does not cause a VM exit, the current guest RIP is pushed on thestack regardless of event type or VM-entry instruction length.
If theencountered exception does cause a VM exit that saves RIP, the saved RIP iscurrent guest RIP.•If the deliver-error-code bit (bit 11) is set in the VM-entry interruptioninformation field, the contents of the VM-entry exception error-code field ispushed on the stack as an error code would be pushed during delivery of anexception.•DR6, DR7, and the IA32_DEBUGCTL MSR are not modified by event injection,even if the event has vector 1 (normal deliveries of debug exceptions, which havevector 1, do update these registers).•If VM entry is injecting a software interrupt and the guest will be in virtual-8086mode (RFLAGS.VM = 1), no general-protection exception can occur due toRFLAGS.IOPL < 3. A VM monitor should check RFLAGS.IOPL before injectingsuch an event and, if desired, inject a general-protection exception instead of asoftware interrupt.•If VM entry is injecting a software interrupt and the guest will be in virtual-8086mode with virtual-8086 mode extensions (RFLAGS.VM = CR4.VME = 1), eventdelivery is subject to VME-based interrupt redirection based on the softwareinterrupt redirection bitmap in the task-state segment (TSS) as follows:— If bit n in the bitmap is clear (where n is the number of the softwareinterrupt), the interrupt is directed to an 8086 program interrupt handler: theprocessor uses a 16-bit interrupt-vector table (IVT) located at linear addresszero.
If the value of RFLAGS.IOPL is less than 3, the following modificationsare made to the value of RFLAGS that is pushed on the stack: IOPL is set to3, and IF is set to the value of VIF.— If bit n in the bitmap is set (where n is the number of the software interrupt),the interrupt is directed to a protected-mode interrupt handler. (In otherwords, the injection is treated as described in the next item.) In this case, thesoftware interrupt does not invoke such a handler if RFLAGS.IOPL < 3 (a1. While these items refer to RIP, the width of the value pushed (16 bits, 32 bits, or 64 bits) isdetermined normally.Vol.
3 22-21VM ENTRIESgeneral-protection exception occurs instead). However, as noted above,RFLAGS.IOPL cannot cause an injected software interrupt to cause such aexception. Thus, in this case, the injection invokes a protected-modeinterrupt handler independent of the value of RFLAGS.IOPL.Injection of events of other types are not subject to this redirection.•If VM entry is injecting a software interrupt (not redirected as described above)or software exception, privilege checking is performed on the IDT descriptorbeing accessed as would be the case for executions of INT n, INT3, or INTO (thedescriptor’s DPL cannot be less than CPL).
There is no checking of RFLAGS.IOPL,even if the guest will be in virtual-8086 mode. Failure of this check may lead to anested exception. Injection of an event with interruption type external interrupt,NMI, hardware exception, and privileged software exception, or with interruptiontype software interrupt and being redirected as described above, do not performthese checks.•If VM entry is injecting a non-maskable interrupt (NMI) and the “virtual NMIs”VM-execution control is 1, virtual-NMI blocking is in effect after VM entry.•The transition causes a last-branch record to be logged if the LBR bit is set in theIA32_DEBUGCTL MSR. This is true even for events such as debug exceptions,which normally clear the LBR bit before delivery.•The last-exception record MSRs (LERs) may be updated based on the setting ofthe LBR bit in the IA32_DEBUGCTL MSR.
Events such as debug exceptions, whichnormally clear the LBR bit before they are delivered, and therefore do notnormally update the LERs, may do so as part of VM-entry event injection.•If injection of an event encounters a nested exception that does not itself cause aVM exit, the value of the EXT bit (bit 0) in any error code pushed on the stack isdetermined as follows:— If event being injected has interruption type external interrupt, NMI,hardware exception, or privileged software exception and encounters anested exception (but does not produce a double fault), the error code for thefirst such exception encountered sets the EXT bit.— If event being injected is a software interrupt or an software exception andencounters a nested exception (but does not produce a double fault), theerror code for the first such exception encountered clears the EXT bit.— If event delivery encounters a nested exception and delivery of thatexception encounters another exception (but does not produce a doublefault), the error code for that exception sets the EXT bit.
If a double fault isproduced, the error code for the double fault is 0000H (the EXT bit is clear).22.5.2VM Exits During Event InjectionAn event being injected never causes a VM exit directly regardless of the settings ofthe VM-execution controls. For example, setting the “NMI exiting” VM-executioncontrol to 1 does not cause a VM exit due to injection of an NMI.22-22 Vol.
3VM ENTRIESHowever, the event-delivery process may lead to a VM exit:•If the vector in the VM-entry interruption-information field identifies a task gatein the IDT, the attempted task switch may cause a VM exit just as it would hadthe injected event occurred during normal execution in VMX non-root operation(see Section 21.6.2).•If event delivery encounters a nested exception, a VM exit may occur dependingon the contents of the exception bitmap (see Section 21.3).•If the “virtualize APIC accesses” VM-execution control is 1 and event deliverygenerates an access to the APIC-access page, that access may cause an APICaccess VM exit (see Section 21.2) or, if the access is a VTPR access, be treated asspecified in Section 21.5.3.If the event-delivery process does cause a VM exit, the processor state before theVM exit is determined just as it would be had the injected event occurred duringnormal execution in VMX non-root operation.
If the injected event directly accesses atask gate that cause a VM exit or if the first nested exception encountered causes aVM exit, information about the injected event is saved in the IDT-vectoring information field (see Section 23.2.3).22.6SPECIAL FEATURES OF VM ENTRYThis section details a variety of features of VM entry. It uses the following terminology: a VM entry is injecting if the valid bit (bit 31) of the VM-entry interruptioninformation field is set.22.6.1Interruptibility StateThe interruptibility-state field in the guest-state area (see Table 20-3) contains bitsthat control blocking by STI, blocking by MOV SS, and blocking by NMI. This fieldimpacts event blocking after VM entry as follows:•If the VM entry is injecting, there is no blocking by STI or by MOV SS followingthe VM entry, regardless of the contents of the interruptibility-state field.•If the VM entry is not injecting, the following apply:— Events are blocked by STI if and only if bit 0 in the interruptibility-state fieldis 1.
Such blocking is cleared after the guest executes one instruction orincurs an exception (including a debug exception made pending by VM entry;see Section 22.6.3).— Events are blocked by MOV SS if and only if bit 1 in the interruptibility-statefield is 1. This may affect the treatment of pending debug exceptions; seeSection 22.6.3. Such blocking is cleared after the guest executes oneinstruction or incurs an exception (including a debug exception made pendingby VM entry).Vol. 3 22-23VM ENTRIES•The blocking of non-maskable interrupts (NMIs) is determined as follows:— If the “virtual NMIs” VM-execution control is 0, NMIs are blocked if bit 3(blocking by NMI) in the interruptibility-state field is 1. If the “NMI exiting”VM-execution control is 0, such blocking remains in effect until IRET isexecuted (even if the instruction generates a fault).