Was defined as 0x1 when it should have been 0x2000 (13th bit of CR4).
See Intel manual 23.7. 0x1 is the VME 'Virtual-8086 Mode Extensions'
bit, which the vmx tests don't exercise.
The correct bit was being set thanks to IA32_VMX_CR4_FIXED{0,1} MSRs
forcing it.
I hacked the test setup to forcibly un-set the bit and observed the
correct #UD VMXON behavior. Adding a test to verify the #UD behavior
is follow-up work.
Signed-off-by: Peter Feiner <pfeiner@xxxxxxxxxx>
---
lib/x86/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/x86/processor.h b/lib/x86/processor.h
index 95cea1a..dff1689 100644
--- a/lib/x86/processor.h
+++ b/lib/x86/processor.h
@@ -21,7 +21,7 @@
#define X86_CR0_WP 0x00010000
#define X86_CR0_AM 0x00040000
#define X86_CR0_PG 0x80000000
-#define X86_CR4_VMXE 0x00000001
+#define X86_CR4_VMXE 0x00002000
#define X86_CR4_TSD 0x00000004
#define X86_CR4_DE 0x00000008
#define X86_CR4_PSE 0x00000010
--
2.7.0.rc3.207.g0ac5344
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
