> From: Don Slutz [mailto:dsl...@verizon.com] > Sent: Tuesday, January 27, 2015 4:31 AM > > The question is about the VM-exit instruction length field. > > This is accessed in xen via: > > __vmread(VM_EXIT_INSTRUCTION_LEN, &inst_len); > > an example of which is in routine get_instruction_length(). > > > Is it architecturally defined that #GP intercept vmexits on IN and OUT > actually set this field? > > What about other instructions?
I didn't catch the question here. There is no such a type called #GP intercept vmexit. That's why the behavior is documented per instruction like you cited below. Thanks Kevin > > My reading of (directly out of > "Intel® 64 and IA-32 Architectures > Software Developer’s Manual > Volume 3 (3A, 3B & 3C): > System Programming Guide > Order Number: 325384-052US, September 2014"): > > > • VM-exit instruction length. This field is used in the following cases: > — For fault-like VM exits due to attempts to execute one of the > following instructions that cause VM exits > unconditionally (see Section 25.1.2) or based on the settings of > VM-execution controls (see Section > 25.1.3): CLTS, CPUID, GETSEC, HLT, IN, INS, INVD, INVEPT, INVLPG, > INVPCID, INVVPID, LGDT, LIDT, LLDT, > LMSW, LTR, MONITOR, MOV CR, MOV DR, MWAIT, OUT, OUTS, PAUSE, > RDMSR, > RDPMC, RDRAND, RDSEED, > RDTSC, RDTSCP, RSM, SGDT, SIDT, SLDT, STR, VMCALL, VMCLEAR, VMLAUNCH, > VMPTRLD, VMPTRST, > VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON, WBINVD, WRMSR, > XRSTORS, > XSETBV, and XSAVES. > > > And > > 25.1.2 > Instructions That Cause VM Exits Unconditionally > The following instructions cause VM exits when they are executed in VMX > non-root operation: CPUID, GETSEC,1 > INVD, and XSETBV. This is also true of instructions introduced with VMX, > which include: INVEPT, INVVPID, > VMCALL,2 VMCLEAR, VMLAUNCH, VMPTRLD, VMPTRST, VMRESUME, VMXOFF, > and VMXON. > 25.1.3 > Instructions That Cause VM Exits Conditionally > Certain instructions cause VM exits in VMX non-root operation depending > on the setting of the VM-execution > controls. The following instructions can cause “fault-like” VM exits > based on the conditions described:3 > • CLTS. The CLTS instruction causes a VM exit if the bits in position 3 > (corresponding to CR0.TS) are set in both > the CR0 guest/host mask and the CR0 read shadow. > • HLT. The HLT instruction causes a VM exit if the “HLT exiting” > VM-execution control is 1. > • > IN, INS/INSB/INSW/INSD, OUT, OUTS/OUTSB/OUTSW/OUTSD. The behavior of > each of these instruc- > tions is determined by the settings of the “unconditional I/O exiting” > and “use I/O bitmaps” VM-execution > controls: > — If both controls are 0, the instruction executes normally. > — If the “unconditional I/O exiting” VM-execution control is 1 and the > “use I/O bitmaps” VM-execution control > is 0, the instruction causes a VM exit. > — If the “use I/O bitmaps” VM-execution control is 1, the instruction > causes a VM exit if it attempts to access > an I/O port corresponding to a bit set to 1 in the appropriate I/O > bitmap (see Section 24.6.4). If an I/O > operation “wraps around” the 16-bit I/O-port space (accesses ports FFFFH > and 0000H), the I/O instruction > causes a VM exit (the “unconditional I/O exiting” VM-execution control > is ignored if the “use I/O bitmaps” > VM-execution control is 1). > See Section 25.1.1 for information regarding the priority of VM exits > relative to faults that may be caused by > the INS and OUTS instructions. > > > > to me says that yes, this field is set on a #GP exit on an IN or an OUT. > But the #GP case is not called out by name. > > To know if it is safe to use VM-exit instruction length in #GP fault > handling code? > > -Don Slutz _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
