Volume 3B System Programming Guide_ Part 2 (794104), страница 31
Текст из файла (страница 31)
The format of the field depends on the cause of the VM exit. See Section23.2.1 for details.20.9.2Information for VM Exits Due to Vectored EventsEvent-specific information is provided for VM exits due to the following vectoredevents: exceptions (including those generated by the instructions INT3, INTO,BOUND, and UD2); external interrupts that occur while the “acknowledge interrupton exit” VM-exit control is 1; and non-maskable interrupts (NMIs). This informationis provided in the following fields:•VM-exit interruption information (32 bits). This field receives basicinformation associated with the event causing the VM exit.
Table 20-13 describesthis field.Vol. 3 20-21VIRTUAL-MACHINE CONTROL STRUCTURESTable 20-13. Format of the VM-Exit Interruption-Information FieldBit Position(s) Content7:0Vector of interrupt or exception10:8Interruption type:0: External interrupt1: Not used2: Non-maskable interrupt (NMI)3: Hardware exception4 – 5: Not used6: Software exception7: Not used11Error code valid (0 = invalid; 1 = valid)12NMI unblocking due to IRET30:13Reserved (cleared to 0)31Valid•VM-exit interruption error code (32 bits).
For VM exits caused by hardwareexceptions that would have delivered an error code on the stack, this fieldreceives that error code.Section 23.2.2 provides details of how these fields are saved on VM exits.20.9.3Information for VM Exits That Occur During Event DeliveryAdditional information is provided for VM exits that occur during event delivery inVMX non-root operation.1 This information is provided in the following fields:•IDT-vectoring information (32 bits). This field receives basic informationassociated with the event that was being delivered when the VM exit occurred.Table 20-14 describes this field.1. This includes cases in which the event delivery was caused by event injection as part ofVM entry; see Section 22.5.2.20-22 Vol.
3VIRTUAL-MACHINE CONTROL STRUCTURESTable 20-14. Format of the IDT-Vectoring Information FieldBitPosition(s)Content7:0Vector of interrupt or exception10:8Interruption type:0: External interrupt1: Not used2: Non-maskable interrupt (NMI)3: Hardware exception4: Software interrupt5: Privileged software exception6: Software exception7: Not used11Error code valid (0 = invalid; 1 = valid)12Undefined30:13Reserved (cleared to 0)31Valid•IDT-vectoring error code (32 bits). For VM exits the occur during delivery ofhardware exceptions that would have delivered an error code on the stack, thisfield receives that error code.See Section 23.2.3 provides details of how these fields are saved on VM exits.20.9.4Information for VM Exits Due to Instruction ExecutionThe following fields are used for VM exits caused by attempts to execute certaininstructions in VMX non-root operation:•VM-exit instruction length (32 bits). For VM exits resulting from instructionexecution, this field receives the length in bytes of the instruction whoseexecution led to the VM exit.1 See Section 23.2.4 for details of when and how thisfield is used.•Guest linear address (64 bits; 32 bits on processors that do not support Intel64 architecture).
This field is used in the following cases:— VM exits due to attempts to execute LMSW with a memory operand.— VM exits due to attempts to execute INS or OUTS.1. This field is also used for VM exits that occur during the delivery of a software interrupt or software exception.Vol. 3 20-23VIRTUAL-MACHINE CONTROL STRUCTURES— VM exits due to system-management interrupts (SMIs) that arriveimmediately after retirement of I/O instructions.See Section 23.2.4 for details of when and how this field is used.•VM-exit instruction information (32 bits). This field is used in the followingcases:— VM exits due to attempts to execute VMCLEAR, VMPTRLD, VMPTRST,VMREAD, VMWRITE, or VMXON.— On some processors, VM exits due to attempts to execute INS or OUTS.1The format of the field depends on the cause of the VM exit.
See Section 23.2.4for details.The following fields (64 bits each; 32 bits on processors that do not support Intel 64architecture) are used only for VM exits due to SMIs that arrive immediately afterretirement of I/O instructions. They provide information about that I/O instruction:••••I/O RCX. The value of RCX before the I/O instruction started.I/O RSI. The value of RSI before the I/O instruction started.I/O RDI. The value of RDI before the I/O instruction started.I/O RIP. The value of RIP before the I/O instruction started (the RIP thataddressed the I/O instruction).20.9.5VM-Instruction Error FieldThe 32-bit VM-instruction error field does not provide information about the mostrecent VM exit.
In fact, it is not modified on VM exits. Instead, it provides informationabout errors encountered by a non-faulting execution of one of the VMX instructions.20.10SOFTWARE ACCESS TO THE VMCS AND RELATEDSTRUCTURESThis section details guidelines that software should observe when accessing a VMCSand related structures. It also provides descriptions of consequences for failing tofollow guidelines.20.10.1 Software Access to the Virtual-Machine Control StructureTo ensure proper processor behavior, software should observe certain guidelineswhen accessing an active VMCS.1. Whether the processor provides this information on these VM exits can be determined by consulting the VMX capability MSR IA32_VMX_BASIC (see Appendix G.1).20-24 Vol.
3VIRTUAL-MACHINE CONTROL STRUCTURESNo VMCS should ever be active on more than one logical processor. If a VMCS is to be“migrated” from one logical processor to another, the first logical processor shouldexecute VMCLEAR for the VMCS (to make it inactive on that logical processor and toensure that all VMCS data are in memory) before the other logical processorexecutes VMPTRLD for the VMCS (to make it active on the second logical processor).Software should never access or modify the VMCS data of an active VMCS using ordinary memory operations, in part because the format used to store the VMCS data isimplementation-specific and not architecturally defined, and also because a logicalprocessor may maintain some VMCS data of an active VMCS on the processor and notin the VMCS region. The following items detail some of the hazards of performingsuch accesses:•Any data read from a VMCS with an ordinary memory read does not reliablyreflect the state of the VMCS.
Results may vary from time to time or from logicalprocessor to logical processor.•Writing to a VMCS with an ordinary memory write is not guaranteed to have adeterministic effect on the VMCS. Doing so may lead to unpredictable behavior.Any or all of the following may occur: (1) VM entries may fail for unexplainedreasons or may load undesired processor state; (2) the processor may notcorrectly support VMX non-root operation as documented in Chapter 21 and maygenerate unexpected VM exits; and (3) VM exits may load undesired processorstate, save incorrect state into the VMCS, or cause the logical processor totransition to a shutdown state.Software can avoid such problems by removing any linear-address mappings to aVMCS region before executing a VMPTRLD for that region and by not remapping ituntil after executing VMCLEAR for that region.Software should use the VMREAD and VMWRITE instructions to access the differentfields in the current VMCS (see Section 20.10.2).Software should initialize all fields in a VMCS (using VMWRITE) before using theVMCS for VM entry.
Failure to do so may result in unpredictable behavior; forexample, a VM entry may fail for unexplained reasons, or a successful transition(VM entry or VM exit) may load processor state with unexpected values.20.10.2 VMREAD, VMWRITE, and Encodings of VMCS FieldsEvery field of the VMCS is associated with a 32-bit value that is its encoding. Theencoding is provided in an operand to VMREAD and VMWRITE when software wishesto read or write that field. These instructions fail if given, in 64-bit mode, an operandthat sets an encoding bit beyond bit 32.
See Chapter 5 of the Intel® 64 and IA-32Architectures Software Developer’s Manual, Volume 2B, for a description of theseinstructions.Vol. 3 20-25VIRTUAL-MACHINE CONTROL STRUCTURESThe structure of the 32-bit encodings of the VMCS components is determined principally by the width of the fields and their function in the VMCS.
See Table 20-15.Table 20-15. Structure of VMCS Component EncodingBit Position(s)Contents31:15Reserved (must be 0)14:13Width:0: 16-bit1: 64-bit2: 32-bit3: natural-width12Reserved (must be 0)11:10Type:0: control1: read-only data2: guest state3: host state9:1Index0Access type (0 = full; 1 = high); must be full for 16-bit, 32-bit, and naturalwidth fieldsThe following items detail the meaning of the bits in each encoding:•Field width. Bits 14:13 encode the width of the field.1) A value of 0 indicates a 16-bit field.b. A value of 1 indicates a 64-bit field.c.A value of 2 indicates a 32-bit field.d.
A value of 3 indicates a natural-width field. Such fields have 64 bits onprocessors that support Intel 64 architecture and 32 bits on processors thatdo not.Fields whose encodings use value 1 are specially treated to allow 32-bit softwareaccess to all 64 bits of the field. Such access is allowed by defining, for each suchfield, an encoding that allows direct access to the high 32 bits of the field. Seebelow.•Field type. Bits 11:10 encode the type of VMCS field: control, guest-state, hoststate, or read-only data. The last category includes the VM-exit information fieldsand the VM-instruction error field.•Index. Bits 9:1 distinguish components with the same field width and type.20-26 Vol. 3VIRTUAL-MACHINE CONTROL STRUCTURES•Access type.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
