Volume 3B System Programming Guide_ Part 2 (794104), страница 37
Текст из файла (страница 37)
(As noted in Section 21.5.3.2, a TPR-shadow update does notoccur following an access that causes a VM exit.)A TPR-shadow update includes the following actions:1. Bits 31:8 at offset 128 on the virtual-APIC page are cleared.2. If the value of bits 3:0 of the TPR threshold VM-execution control field is greaterthan the value of bits 7:4 at offset 128 on the virtual-APIC page, a VM exit willoccur.TPR-shadow updates 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).1 TPRshadow updates (and any VM exits they cause) are not blocked if RFLAGS.IF = 0 orby the MOV SS, POP SS, or STI instructions.1. Because task switches cannot occur in VMX non-root operation (see Section 21.6.2), the relativepriority of TPR-shadow updates and “trap on task switch” events is not defined.Vol.
3 21-17VMX NON-ROOT OPERATION21.6OTHER CHANGES IN VMX NON-ROOT OPERATIONTreatments of event blocking and of task switches differ in VMX non-root operation asdescribed in the following sections.21.6.1Event BlockingEvent blocking is modified in VMX non-root operation as follows:•If the “external-interrupt exiting” VM-execution control is 1, RFLAGS.IF does notcontrol the blocking of external interrupts. In this case, an external interrupt thatis not blocked for other reasons causes a VM exit (even if RFLAGS.IF = 0).•If the “external-interrupt exiting” VM-execution control is 1, external interruptsmay or may not be blocked by STI or by MOV SS (behavior is implementationspecific).•If the “NMI exiting” VM-execution control is 1, non-maskable interrupts (NMIs)may or may not be blocked by STI or by MOV SS (behavior is implementationspecific).21.6.2Treatment of Task SwitchesTask switches are not allowed in VMX non-root operation.
Any attempt to effect atask switch in VMX non-root operation causes a VM exit. However, the followingchecks are performed (in the order indicated), possibly resulting in a fault, beforethere is any possibility of a VM exit due to task switch:1. If a task gate is being used, appropriate checks are made on its P bit and on theproper values of the relevant privilege fields. The following cases detail theprivilege checks performed:a.
If CALL, INT n, or JMP accesses a task gate in IA-32e mode, a generalprotection exception occurs.b. If CALL, INT n, INT3, INTO, or JMP accesses a task gate outside IA-32e mode,privilege-levels checks are performed on the task gate but, if they pass,privilege levels are not checked on the referenced task-state segment (TSS)descriptor.c.If CALL or JMP accesses a TSS descriptor directly in IA-32e mode, a generalprotection exception occurs.d. If CALL or JMP accesses a TSS descriptor directly outside IA-32e mode,privilege levels are checked on the TSS descriptor.e.
If a non-maskable interrupt (NMI), an exception, or an external interruptaccesses a task gate in the IDT in IA-32e mode, a general-protectionexception occurs.21-18 Vol. 3VMX NON-ROOT OPERATIONf.If a non-maskable interrupt (NMI), an exception other than breakpointexceptions (#BP) and overflow exceptions (#OF), or an external interruptaccesses a task gate in the IDT outside IA-32e mode, no privilege checks areperformed.g. If IRET is executed with RFLAGS.NT = 1 in IA-32e mode, a generalprotection exception occurs.h. If IRET is executed with RFLAGS.NT = 1 outside IA-32e mode, a TSSdescriptor is accessed directly and no privilege checks are made.2. Checks are made on the new TSS selector (for example, that is within GDTlimits).3.
The new TSS descriptor is read. (A page fault results if a relevant GDT page is notpresent).4. The TSS descriptor is checked for proper values of type (depends on type of taskswitch), P bit, S bit, and limit.Only if checks 1–4 all pass (do not generate faults) might a VM exit occur. However,the ordering between a VM exit due to a task switch and a page fault resulting fromaccessing the old TSS or the new TSS is implementation-specific.
Some logicalprocessors may generate a page fault (instead of a VM exit due to a task switch) ifaccessing either TSS would cause a page fault. Other logical processors maygenerate a VM exit due to a task switch even if accessing either TSS would cause apage fault.If an attempt at a task switch through a task gate in the IDT causes an exception(before generating a VM exit due to the task switch) and that exception causes aVM exit, information about the event whose delivery that accessed the task gate isrecorded in the IDT-vectoring information fields and information about the exceptionthat caused the VM exit is recorded in the VM-exit interruption-information fields.See Section 23.2.
The fact that a task gate was being accessed is not recorded in theVMCS.If an attempt at a task switch through a task gate in the IDT causes VM exit due tothe task switch, information about the event whose delivery accessed the task gateis recorded in the IDT-vectoring fields of the VMCS.
Since the cause of such a VM exitis a task switch and not an interruption, the valid bit for the VM-exit interruptioninformation field is 0. See Section 23.2.Vol. 3 21-19VMX NON-ROOT OPERATION21-20 Vol. 3CHAPTER 22VM ENTRIESSoftware can enter VMX non-root operation using either of the VM-entry instructionsVMLAUNCH and VMRESUME. VMLAUNCH can be used only with a VMCS whose launchstate is clear and VMRESUME can be used only with a VMCS whose the launch stateis launched. VMLAUNCH should be used for the first VM entry after VMCLEAR; VMRESUME should be used for subsequent VM entries with the same VMCS.Each VM entry performs the following steps in the order indicated:1.
Basic checks are performed to ensure that VM entry can commence(Section 22.1).2. The control and host-state areas of the VMCS are checked to ensure that they areproper for supporting VMX non-root operation and that the VMCS is correctlyconfigured to support the next VM exit (Section 22.2).3. The following may be performed in parallel or in any order (Section 22.3):•The guest-state area of the VMCS is checked to ensure that, after theVM entry completes, the state of the logical processor is consistent withIA-32 and Intel 64 architectures.•Processor state is loaded from the guest-state area and based on theVM-entry controls.•Address-range monitoring is cleared.4.
MSRs are loaded from the VM-entry MSR-load area (Section 22.4).5. If VMLAUNCH is being executed, the launch state of the VMCS is set to“launched.”6. An event may be injected in the guest context (Section 22.5).Steps 1–4 above perform checks that may cause VM entry to fail. Such failures occurin one of the following three ways:•Some of the checks in Section 22.1 may generate ordinary faults (for example,an invalid-opcode exception). Such faults are delivered normally.•Some of the checks in Section 22.1 and all the checks in Section 22.2 causecontrol to pass to the instruction following the VM-entry instruction. The failure isindicated by setting RFLAGS.ZF1 (if there is a current VMCS) or RFLAGS.CF (ifthere is no current VMCS). If there is a current VMCS, an error number indicating1.
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 IA-32 processors,this notation refers to the 32-bit forms of those registers (EAX, EIP, ESP, EFLAGS, etc.). In a fewplaces, notation such as EAX is used to refer specifically to lower 32 bits of the indicated register.Vol.
3 22-1VM ENTRIESthe cause of the failure is stored in the VM-instruction error field. See Appendix Ifor the error numbers.•The checks in Section 22.3 and Section 22.4 cause processor state to be loadedfrom the host-state area of the VMCS (as would be done on a VM exit).Information about the failure is stored in the VM-exit information fields.
SeeSection 22.7 for details.EFLAGS.TF = 1 causes a VM-entry instruction to generate a single-step debug exception only if failure of one of the checks in Section 22.1 and Section 22.2 causescontrol to pass to the following instruction. A VM-entry does not generate a singlestep debug exception in any of the following cases: (1) the instruction generates afault; (2) failure of one of the checks in Section 22.3 or in loading MSRs causesprocessor state to be loaded from the host-state area of the VMCS; or (3) the instruction passes all checks in Section 22.1, Section 22.2, and Section 22.3 and there is nofailure in loading MSRs.Section 24.16 describes the dual-monitor treatment of system-management interrupts (SMIs) and system-management mode (SMM).
Under this treatment, coderunning in SMM returns using VM entries instead of the RSM instruction. A VM entryreturns from SMM if it is executed in SMM and the “entry to SMM” VM-entry controlis 0. VM entries that return from SMM differ from ordinary VM entries in ways thatare detailed in Section 24.16.4.22.1BASIC VM-ENTRY CHECKSBefore a VM entry commences, the current state of the logical processor is checkedin the following order:1. If the logical processor is in virtual-8086 mode or compatibility mode, aninvalid-opcode exception is generated.2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
