Volume 3B System Programming Guide_ Part 2 (794104), страница 32
Текст из файла (страница 32)
Bit 0 must be 0 for all fields except for 64-bit fields (those withfield-width 1; see above). A VMREAD or VMWRITE using an encoding with this bitcleared to 0 accesses the entire field. For a 64-bit field with field-width 1, aVMREAD or VMWRITE using an encoding with this bit set to 1 accesses only thehigh 32 bits of the field.Appendix H gives the encodings of all fields in the VMCS.The following describes the operation of VMREAD and VMWRITE based on processormode, VMCS-field width, and access type:•16-bit fields:— A VMREAD returns the value of the field in bits 15:0 of the destinationoperand; other bits of the destination operand are cleared to 0.— A VMWRITE writes the value of bits 15:0 of the source operand into the VMCSfield; other bits of the source operand are not used.•32-bit fields:— A VMREAD returns the value of the field in bits 31:0 of the destinationoperand; in 64-bit mode, bits 63:32 of the destination operand are cleared to0.— A VMWRITE writes the value of bits 31:0 of the source operand into the VMCSfield; in 64-bit mode, bits 63:32 of the source operand are not used.•64-bit fields and natural-width fields using the full access type outside IA-32emode.— A VMREAD returns the value of bits 31:0 of the field in its destinationoperand; bits 63:32 of the field are ignored.— A VMWRITE writes the value of its source operand to bits 31:0 of the field andclears bits 63:32 of the field.•64-bit fields and natural-width fields using the full access type in 64-bit mode(only on processors that support Intel 64 architecture).— A VMREAD returns the value of the field in bits 63:0 of the destinationoperand— A VMWRITE writes the value of bits 63:0 of the source operand into the VMCSfield.•64-bit fields using the high access type.— A VMREAD returns the value of bits 63:32 of the field in bits 31:0 of thedestination operand; in 64-bit mode, bits 63:32 of the destination operandare cleared to 0.— A VMWRITE writes the value of bits 31:0 of the source operand to bits 63:32of the field; in 64-bit mode, bits 63:32 of the source operand are not used.Software seeking to read a 64-bit field outside IA-32e mode can use VMREAD withthe full access type (reading bits 31:0 of the field) and VMREAD with the high accesstype (reading bits 63:32 of the field); the order of the two VMREAD executions is notVol.
3 20-27VIRTUAL-MACHINE CONTROL STRUCTURESimportant. Software seeking to modify a 64-bit field outside IA-32e mode should firstuse VMWRITE with the full access type (establishing bits 31:0 of the field whileclearing bits 63:32) and then use VMWRITE with the high access type (establishingbits 63:32 of the field).20.10.3 Software Access to Related StructuresIn addition to data in the VMCS region itself, VMX non-root operation can becontrolled by data structures that are referenced by pointers in a VMCS (for example,the I/O bitmaps). Note that, while the pointers to these data structures are parts ofthe VMCS, the data structures themselves are not.
They are not accessible usingVMREAD and VMWRITE but by ordinary memory writes.Software should ensure that each such data structure is modified only when nological processor with a current VMCS that references it is in VMX non-root operation.Doing otherwise may lead to unpredictable behavior (including behaviors identified inSection 20.10.1).20.10.4 VMXON RegionBefore executing VMXON, software allocates a region of memory (called the VMXONregion)1 that the logical processor uses to support VMX operation. The physicaladdress of this region (the VMXON pointer) is provided in an operand to VMXON.
TheVMXON pointer is subject to the limitations that apply to VMCS pointers:••The VMXON pointer must be 4-KByte aligned (bits 11:0 must be zero).On processors that support Intel 64 architecture, the VMXON pointer must notset any bits beyond the processor’s physical-address width.2 On processors thatdo not support Intel 64 architecture, the VMXON pointer must not set any bits inthe range 63:32.Before executing VMXON, software should write the VMCS revision identifier (seeSection 20.2) to the VMXON region. It need not initialize the VMXON region in anyother way.
Software should use a separate region for each logical processor andshould not access or modify the VMXON region of a logical processor between execution of VMXON and VMXOFF on that logical processor. Doing otherwise may lead tounpredictable behavior (including behaviors identified in Section 20.10.1).1. The amount of memory required for the VMXON region is the same as that required for a VMCSregion. This size is implementation specific and can be determined by consulting the VMX capability MSR IA32_VMX_BASIC (see Appendix G.1).2.
Software can determine a processor’s physical-address width by executing CPUID with80000008H in EAX. The physical-address width is returned in bits 7:0 of EAX.20-28 Vol. 3VIRTUAL-MACHINE CONTROL STRUCTURES20.11USING VMCLEAR TO INITIALIZE A VMCS REGIONA processor may use the VMCS data portion of a VMCS region to maintain implementation-specific information about the VMCS. When software first allocates a region ofmemory for use as a VMCS region, the data in that region may be interpreted in animplementation-specific manner. In addition to its other functions, the VMCLEARinstruction initializes any implementation-specific information in the VMCS regionreferenced by its operand. To avoid the uncertainties of implementation-specificbehavior, software should execute VMCLEAR on a VMCS region before making thecorresponding VMCS active with VMPTRLD.A logical processor uses the VMCS region to maintain the launch state of the corresponding VMCS.
The launch state may be clear or launched. The VMCLEAR instruction puts the VMCS referenced by its operand into the clear state. The VMLAUNCHinstruction requires a VMCS whose launch state is clear and changes its launch stateto launched. The VMRESUME instruction requires a VMCS whose launch state islaunched. There are no other ways to modify the launch state of a VMCS (it cannot bemodified using VMWRITE) and there is no direct way to read it (it cannot be readusing VMREAD). Improper software usage (for example, software writing to theVMCS data of an active VMCS) may leave the launch state undefined.The following software usage is consistent with these limitations:••VMCLEAR should be executed for a VMCS before it is used for VM entry.•VMRESUME should be used for any subsequent VM entry using a VMCS (until thenext execution of VMCLEAR for the VMCS).VMLAUNCH should be used for the first VM entry using a VMCS after VMCLEARhas been executed for that VMCS.It is expected that, in general, VMRESUME will have lower latency than VMLAUNCH.Since “migrating” a VMCS from one logical processor to another requires use ofVMCLEAR (see Section 20.10.1), which sets the launch state of the VMCS to “clear,”such migration requires the next VM entry to be performed using VMLAUNCH.
Software developers can avoid the performance cost of increased VM-entry latency byavoiding unnecessary migration of a VMCS from one logical processor to another.Vol. 3 20-29VIRTUAL-MACHINE CONTROL STRUCTURES20-30 Vol. 3CHAPTER 21VMX NON-ROOT OPERATIONIn a virtualized environment using VMX, the guest software stack typically runs on alogical processor in VMX non-root operation. This mode of operation is similar to thatof ordinary processor operation outside of the virtualized environment.
This chapterdescribes the differences between VMX non-root operation and ordinary processoroperation with special attention to causes of VM exits (which bring a logical processorfrom VMX non-root operation to root operation). The differences between VMX nonroot operation and ordinary processor operation are described in the followingsections:••••••Section 21.1, “Instructions That Cause VM Exits”Section 21.2, “APIC-Access VM Exits”Section 21.3, “Other Causes of VM Exits”Section 21.4, “Changes to Instruction Behavior in VMX Non-Root Operation”Section 21.5, “APIC Accesses That Do Not Cause VM Exits”Section 21.6, “Other Changes in VMX Non-Root Operation”Chapter 20, “Virtual-Machine Control Structures,” describes the data control structure that governs VMX operation (root and non-root). Chapter 22, “VM Entries,”describes the operation of VM entries which allow the processor to transition fromVMX root operation to non-root operation.21.1INSTRUCTIONS THAT CAUSE VM EXITSCertain instructions may cause VM exits if executed in VMX non-root operation.Unless otherwise specified, such VM exits are “fault-like,” meaning that the instruction causing the VM exit does not execute and no processor state is updated by theinstruction.
Section 23.1 details architectural state in the context of a VM exit.Section 21.1.1 defines the prioritization between faults and VM exits for instructionssubject to both. Section 21.1.2 identifies instructions that cause VM exits wheneverthey are executed in VMX non-root operation (and thus can never be executed inVMX non-root operation). Section 21.1.3 identifies instructions that cause VM exitsdepending on the settings of certain VM-execution control fields (see Section 20.6).21.1.1Relative Priority of Faults and VM ExitsThe following principles describe the ordering between existing faults and VM exits:•Certain exceptions have priority over VM exits. These include invalid-opcodeexceptions, faults based on privilege level, and general-protection exceptionsVol.
3 21-1VMX NON-ROOT OPERATIONthat are based on checking I/O permission bits in the task-state segment (TSS).For example, execution of RDMSR with CPL = 3 generates a general-protectionexception and not a VM exit.1•Faults incurred while fetching instruction operands have priority over VM exitsthat are conditioned based on the contents of those operands (see LMSW inSection 21.1.3).•VM exits caused by execution of the INS and OUTS instructions (resulting eitherbecause the “unconditional I/O exiting” VM-execution control is 1 or because the“use I/O bitmaps control is 1) have priority over the following faults:— A general-protection fault due to the relevant segment (ES for INS; DS forOUTS unless overridden by an instruction prefix) being unusable— A general-protection fault due to an offset beyond the limit of the relevantsegment— An alignment-check exception•Fault-like VM exits have priority over general-protection exceptions other thanthose mentioned above.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
