VM-exit instruction length and #GP fault on IN.

* VM-exit instruction length and #GP fault on IN.
@ 2015-01-26 20:31 Don Slutz
  2015-01-27  5:48 ` Tian, Kevin
  0 siblings, 1 reply; 3+ messages in thread
From: Don Slutz @ 2015-01-26 20:31 UTC (permalink / raw)
  To: Jun Nakajima, Eddie Dong, Kevin Tian; +Cc: Jan Beulich, xen-devel

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?

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

^ permalink raw reply	[flat|nested] 3+ messages in thread