Re: [Xen-devel] VM-exit instruction length and #GP fault on IN.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Don Slutz [mailto:dslutz@xxxxxxxxxxx]
> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel