* Interested in working for GSoC project
@ 2013-04-13 18:24 Mohit Dhingra
2013-04-14 8:18 ` Jan Kiszka
0 siblings, 1 reply; 4+ messages in thread
From: Mohit Dhingra @ 2013-04-13 18:24 UTC (permalink / raw)
To: kvm
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
Hi All,
I am Mohit Dhingra, planning to work in GSoC project "Improve nested
virtualization support for x86". I got in touch with Jan
(jan.kiszka@web.de) few days back.
As suggested by him, I am trying to write a simple unit test which
tests the "vmx" functions. To start with, I have written a small code
which checks whether "vmx" functionality is available on the current
processor or not[1].
I have used "cpuid" to check the VMX functionality. Before executing
cpuid, eax is set to 1. cpuid then puts the feature flags in ecx and
edx registers. Bit5 in ecx register tells whether VMX feature is
present or not. I am attaching the patch along with this mail.
But there is a problem that I am facing. CPUID behaves differently
when I run it using qemu-kvm, and when I run it directly in user mode.
Please check the below output. It would be great if someone can
please help me out.
----------------------------------------------------------------------------------------------------
Using qemu-kvm
Command :
qemu-kvm -device testdev,chardev=testlog -chardev
file,id=testlog,path=msr.out -serial stdio -kernel ./x86/vmx_test.flat
Output :
Warning: default mac address being used, creating potential for address conflict
enabling apic
Feauture Flag returned in ecx : 0x80802001 VMX capabilities not present !
Vendor ID (returned by CPUID) : GenuineIntel
---------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
Executing directly
Compile :
gcc -o gcc_output x86/vmx_test.c
Executing :
./gcc_output
Output :
Feauture Flag returned in ecx : 0x98e3bd VMX capabilities present !
Vendor ID (returned by CPUID) : GenuineIntel
----------------------------------------------------------------------------------------------------------
[1] Intel Processor Identification and the CPUID Instruction
----------------------------
Thanks & Regards
Mohit Dhingra
+919611190435
[-- Attachment #2: check_vmx_capabilities.patch --]
[-- Type: application/octet-stream, Size: 4189 bytes --]
From 5c10b231c892150927f37788b7e7ddf5290c74e4 Mon Sep 17 00:00:00 2001
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 13 Apr 2013 23:43:23 +0530
Subject: [PATCH 1/3] Unit test for checking VMX capabilities
---
x86/vmx_test.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 x86/vmx_test.c
diff --git a/x86/vmx_test.c b/x86/vmx_test.c
new file mode 100644
index 0000000..ee7706e
--- /dev/null
+++ b/x86/vmx_test.c
@@ -0,0 +1,58 @@
+
+#include "../lib/libcflat.h"
+#include "../lib/x86/processor.h"
+#include "../lib/x86/msr.h"
+
+
+
+int main(int ac, char **av)
+{
+
+ int eax_initialize = 1;
+ uint32_t test_vmx_capabilities = 0;
+
+
+
+ int code = 0;
+
+ union {
+ uint32_t where[4];
+ char vendor[17];
+ }s;
+
+
+
+ asm volatile ("mov %1, %%eax\n\t" // mov source destination
+ "cpuid\n\t" // When eax = 1, cpuid puts Feature Flags in ecx and edx registers. Bit 5 in ecx tells whether VMX is supported or not.
+// "and $0x20, %%ecx\n\t" // ANDing ecx with 0x20 (00100000), if it results in non-zero, then VMX capabilities are present.
+ "mov %%ecx, %0" // Storing the result into test_vmx_capabilities
+
+ :"=r"(test_vmx_capabilities) // Ouputs : test_vmx_capabilities
+ :"r"(eax_initialize) // Inputs : eax_initialize
+ :"eax","ecx");
+
+
+ printf("Feauture Flag returned in ecx : 0x%x ", test_vmx_capabilities);
+
+ if ( test_vmx_capabilities & 0x20 )
+ printf ("VMX capabilities present ! \n");
+ else
+ printf ("VMX capabilities not present ! \n");
+
+
+
+ // Prints vendor ID
+
+ asm volatile("cpuid":"=a"(*s.where),"=b"(*(s.where+1)),
+ "=c"(*(s.where+3)),"=d"(*(s.where+2)):"a"(code));
+
+ s.vendor[17] = '\0';
+
+ printf("Vendor ID (returned by CPUID) : %s\n", (s.vendor+4));
+
+
+
+
+
+ return 1;
+}
--
1.7.3.4
From 8f1f5ca9505352d3139f648c7a359ecfaaf9088a Mon Sep 17 00:00:00 2001
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 13 Apr 2013 23:43:54 +0530
Subject: [PATCH 2/3] Unit test for checking VMX capabilities
---
config-x86-common.mak | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/config-x86-common.mak b/config-x86-common.mak
index 1f0f1ba..df2a42e 100644
--- a/config-x86-common.mak
+++ b/config-x86-common.mak
@@ -31,7 +31,7 @@ FLATLIBS = lib/libcflat.a $(libgcc)
tests-common = $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \
$(TEST_DIR)/smptest.flat $(TEST_DIR)/port80.flat \
- $(TEST_DIR)/realmode.flat $(TEST_DIR)/msr.flat \
+ $(TEST_DIR)/realmode.flat $(TEST_DIR)/msr.flat $(TEST_DIR)/vmx_test.flat \
$(TEST_DIR)/hypercall.flat $(TEST_DIR)/sieve.flat \
$(TEST_DIR)/kvmclock_test.flat $(TEST_DIR)/eventinj.flat \
$(TEST_DIR)/s3.flat $(TEST_DIR)/pmu.flat \
@@ -79,6 +79,8 @@ $(TEST_DIR)/realmode.o: bits = 32
$(TEST_DIR)/msr.elf: $(cstart.o) $(TEST_DIR)/msr.o
+$(TEST_DIR)/vmx_test.elf: $(cstart.o) $(TEST_DIR)/vmx_test.o
+
$(TEST_DIR)/idt_test.elf: $(cstart.o) $(TEST_DIR)/idt_test.o
$(TEST_DIR)/xsave.elf: $(cstart.o) $(TEST_DIR)/xsave.o
--
1.7.3.4
From 4fb354449e5a718fbf1c0124b37ef51ad32119f8 Mon Sep 17 00:00:00 2001
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sat, 13 Apr 2013 23:44:20 +0530
Subject: [PATCH 3/3] Unit test for checking VMX capabilities
---
x86/unittests.cfg | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index 5e08c55..6230acf 100644
--- a/x86/unittests.cfg
+++ b/x86/unittests.cfg
@@ -66,6 +66,29 @@ file = idt_test.flat
[msr]
file = msr.flat
+[vmx_test]
+file = vmx_test.flat
+
+[port80]
+file = port80.flat
+
+[realmode]
+file = realmode.flat
+
+[sieve]
+file = sieve.flat
+
+[tsc]
+file = tsc.flat
+
+[xsave]
+file = xsave.flat
+
+[rmap_chain]
+file = rmap_chain.flat
+
+[svm]
+file = svm.flat
[port80]
file = port80.flat
@@ -101,4 +124,4 @@ extra_params = --append "10000000 `date +%s`"
[pcid]
file = pcid.flat
-extra_params = -cpu qemu64,+pcid
\ No newline at end of file
+extra_params = -cpu qemu64,+pcid
--
1.7.3.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: Interested in working for GSoC project
2013-04-13 18:24 Interested in working for GSoC project Mohit Dhingra
@ 2013-04-14 8:18 ` Jan Kiszka
2013-04-14 10:29 ` Kashyap Chamarthy
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kiszka @ 2013-04-14 8:18 UTC (permalink / raw)
To: Mohit Dhingra; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On 2013-04-13 20:24, Mohit Dhingra wrote:
> Hi All,
>
> I am Mohit Dhingra, planning to work in GSoC project "Improve nested
> virtualization support for x86". I got in touch with Jan
> (jan.kiszka@web.de) few days back.
>
> As suggested by him, I am trying to write a simple unit test which
> tests the "vmx" functions. To start with, I have written a small code
> which checks whether "vmx" functionality is available on the current
> processor or not[1].
>
> I have used "cpuid" to check the VMX functionality. Before executing
> cpuid, eax is set to 1. cpuid then puts the feature flags in ecx and
> edx registers. Bit5 in ecx register tells whether VMX feature is
> present or not. I am attaching the patch along with this mail.
Hint regarding assembly usage: Try to minimize the number of
instructions. Check, e.g., how the kernel implements cpuid. Result
evaluation can perfectly be done in C.
>
> But there is a problem that I am facing. CPUID behaves differently
> when I run it using qemu-kvm, and when I run it directly in user mode.
> Please check the below output. It would be great if someone can
> please help me out.
To enable nested VMX, you need to tweak two things: first, you need
nested=1 as parameter for kvm_intel. And, second, you have to select a
CPU type via QEMU (-cpu) that supports VMX or explicitly add that
feature to the selected CPU (-cpu ...,+vmx).
By default, only core[2]duo and the synthetic KVM type "host" come with
VMX enabled, not much more modern Intel CPU like Nehalem or SandyBridge.
That's inconsistent, and if you want to fix something in QEMU, you could
check which CPU types in qemu/target-i386/cpu.c lack the flag and post a
patch to change this.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Interested in working for GSoC project
2013-04-14 8:18 ` Jan Kiszka
@ 2013-04-14 10:29 ` Kashyap Chamarthy
2013-04-20 21:01 ` Mohit Dhingra
0 siblings, 1 reply; 4+ messages in thread
From: Kashyap Chamarthy @ 2013-04-14 10:29 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Mohit Dhingra, kvm
On Sun, Apr 14, 2013 at 1:48 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> On 2013-04-13 20:24, Mohit Dhingra wrote:
>> Hi All,
>>
>> I am Mohit Dhingra, planning to work in GSoC project "Improve nested
>> virtualization support for x86". I got in touch with Jan
>> (jan.kiszka@web.de) few days back.
>>
>> As suggested by him, I am trying to write a simple unit test which
>> tests the "vmx" functions. To start with, I have written a small code
>> which checks whether "vmx" functionality is available on the current
>> processor or not[1].
>>
>> I have used "cpuid" to check the VMX functionality. Before executing
>> cpuid, eax is set to 1. cpuid then puts the feature flags in ecx and
>> edx registers. Bit5 in ecx register tells whether VMX feature is
>> present or not. I am attaching the patch along with this mail.
>
> Hint regarding assembly usage: Try to minimize the number of
> instructions. Check, e.g., how the kernel implements cpuid. Result
> evaluation can perfectly be done in C.
>
>>
>> But there is a problem that I am facing. CPUID behaves differently
>> when I run it using qemu-kvm, and when I run it directly in user mode.
>> Please check the below output. It would be great if someone can
>> please help me out.
>
> To enable nested VMX, you need to tweak two things: first, you need
> nested=1 as parameter for kvm_intel. And, second, you have to select a
> CPU type via QEMU (-cpu) that supports VMX or explicitly add that
> feature to the selected CPU (-cpu ...,+vmx).
In addendum to Jan's above info,
I posted some notes here while testing it on Fedora, see if its any helpful:
- http://kashyapc.wordpress.com/tag/nested-virtualization/
- https://github.com/kashyapc/nested-virt-notes-intel-f18
>
> By default, only core[2]duo and the synthetic KVM type "host" come with
> VMX enabled, not much more modern Intel CPU like Nehalem or SandyBridge.
> That's inconsistent, and if you want to fix something in QEMU, you could
> check which CPU types in qemu/target-i386/cpu.c lack the flag and post a
> patch to change this.
>
> Jan
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Interested in working for GSoC project
2013-04-14 10:29 ` Kashyap Chamarthy
@ 2013-04-20 21:01 ` Mohit Dhingra
0 siblings, 0 replies; 4+ messages in thread
From: Mohit Dhingra @ 2013-04-20 21:01 UTC (permalink / raw)
To: Kashyap Chamarthy; +Cc: Jan Kiszka, kvm
[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]
Hi Jan/ Kashyap/ All,
Thanks for the tips! It was really helpful. I was using a very old
version of kvm_intel module and it didn't have "nested" capabilities.
Now, I am using "-cpu core2duo,+vmx" option and kvm-intel.ko is also
inserted using nested=1. And, the CPUID returned the correct info, it
had VMX capabilities. Hence the test is passed.
Secondly, I am trying to test bit 13 of CR4 register, which is
necessary to be set before using instructions like vmxon. I am not
sure when and how is this bit set, or it never gets set in the tests?
I am attaching the patch, which as of now, first prints the vendor ID,
and Passes VMX capabilities test, and Fails for testing CR4.VMXE bit.
Command :
qemu-kvm -device testdev,chardev=testlog -chardev
file,id=testlog,path=msr.out -serial stdio -cpu core2duo,+vmx -kernel
./x86/vmx_test.flat
Output :
Vendor ID : GenuineIntel
VMX_CAPABILITIES_GUEST: PASS
CONTROL_REGISTER_VMX_ON: FAIL
----------------------------
Thanks & Regards
Mohit Dhingra
+919611190435
On 14 April 2013 15:59, Kashyap Chamarthy <kashyap.cv@gmail.com> wrote:
> On Sun, Apr 14, 2013 at 1:48 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2013-04-13 20:24, Mohit Dhingra wrote:
>>> Hi All,
>>>
>>> I am Mohit Dhingra, planning to work in GSoC project "Improve nested
>>> virtualization support for x86". I got in touch with Jan
>>> (jan.kiszka@web.de) few days back.
>>>
>>> As suggested by him, I am trying to write a simple unit test which
>>> tests the "vmx" functions. To start with, I have written a small code
>>> which checks whether "vmx" functionality is available on the current
>>> processor or not[1].
>>>
>>> I have used "cpuid" to check the VMX functionality. Before executing
>>> cpuid, eax is set to 1. cpuid then puts the feature flags in ecx and
>>> edx registers. Bit5 in ecx register tells whether VMX feature is
>>> present or not. I am attaching the patch along with this mail.
>>
>> Hint regarding assembly usage: Try to minimize the number of
>> instructions. Check, e.g., how the kernel implements cpuid. Result
>> evaluation can perfectly be done in C.
>>
>>>
>>> But there is a problem that I am facing. CPUID behaves differently
>>> when I run it using qemu-kvm, and when I run it directly in user mode.
>>> Please check the below output. It would be great if someone can
>>> please help me out.
>>
>> To enable nested VMX, you need to tweak two things: first, you need
>> nested=1 as parameter for kvm_intel. And, second, you have to select a
>> CPU type via QEMU (-cpu) that supports VMX or explicitly add that
>> feature to the selected CPU (-cpu ...,+vmx).
>
> In addendum to Jan's above info,
>
> I posted some notes here while testing it on Fedora, see if its any helpful:
>
> - http://kashyapc.wordpress.com/tag/nested-virtualization/
> - https://github.com/kashyapc/nested-virt-notes-intel-f18
>
>>
>> By default, only core[2]duo and the synthetic KVM type "host" come with
>> VMX enabled, not much more modern Intel CPU like Nehalem or SandyBridge.
>> That's inconsistent, and if you want to fix something in QEMU, you could
>> check which CPU types in qemu/target-i386/cpu.c lack the flag and post a
>> patch to change this.
>>
>> Jan
>>
[-- Attachment #2: vmx_test.patch --]
[-- Type: text/x-patch, Size: 5019 bytes --]
From 01f3cc5e424dca53a94f0cb349447f5c436a301b Mon Sep 17 00:00:00 2001
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sun, 21 Apr 2013 02:18:32 +0530
Subject: [PATCH 1/3] Unit test for checking VMX capabilities
---
x86/vmx_test.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 x86/vmx_test.c
diff --git a/x86/vmx_test.c b/x86/vmx_test.c
new file mode 100644
index 0000000..d928f07
--- /dev/null
+++ b/x86/vmx_test.c
@@ -0,0 +1,98 @@
+
+#include "libcflat.h"
+#include "processor.h"
+#include "msr.h"
+
+
+struct vmx_info {
+ char *name;
+ int (*test_case)();
+};
+
+int test_vmx_capabilities(); // Returns 1 if VMX capabilities are present in the Guest, else Returns 0
+int test_cr4_vmx_set(); // Returns 1 if VMX bit is set in CR4 Register ( Must before executing instructions like vmxon )
+void VendorId(); // Prints Vendor ID
+
+
+struct vmx_info test_cases_array[]= {
+ {"VMX_CAPABILITIES_GUEST" , test_vmx_capabilities},
+ {"CONTROL_REGISTER_VMX_ON", test_cr4_vmx_set}
+};
+
+
+
+int main(int ac, char **av)
+{
+ int count = 0;
+
+ VendorId();
+
+ for( count = 0 ; count < (sizeof(test_cases_array)/sizeof(struct vmx_info)) ; count++)
+ {
+ printf( "%s: %s\n", test_cases_array[count].name, (test_cases_array[count].test_case() ? "PASS" : "FAIL") );
+ }
+
+
+ return 1;
+}
+
+
+int test_vmx_capabilities()
+{
+
+ int eax_initialize = 1;
+ uint32_t test_vmx_capabilities = 0;
+
+ asm volatile ("mov %1, %%eax\n\t" // mov source destination
+ "cpuid\n\t" // When eax = 1, cpuid puts Feature Flags in ecx and edx registers.
+ "mov %%ecx, %0" // Storing the result into test_vmx_capabilities
+
+ :"=r"(test_vmx_capabilities) // Ouputs : test_vmx_capabilities
+ :"r"(eax_initialize) // Inputs : eax_initialize
+ :"eax","ecx");
+
+// printf("Feauture Flag returned in ecx : 0x%x ", test_vmx_capabilities);
+
+ if ( test_vmx_capabilities & 0x20 ) // ANDing ecx with 0x20 (00100000), if it results in non-zero, then VMX capabilities are present.
+ return 1;
+ else
+ return 0;
+
+}
+
+
+
+int test_cr4_vmx_set()
+{
+ unsigned long result;
+
+ //CR4 cr4_reg;
+
+ asm volatile("movq %%cr4, %%rax\n\t"
+ : "=a"(result) :: );
+
+ if ( result & 0x2000 ) // Bit 13 of CR4 should be set to use commands like vmxon
+ return 1;
+
+ return 0;
+
+}
+
+
+// Prints vendor ID
+void VendorId()
+{
+ int code = 0;
+
+ union {
+ uint32_t where[4];
+ char vendor[17];
+ }s;
+
+ asm volatile("cpuid":"=a"(*s.where),"=b"(*(s.where+1)),"=c"(*(s.where+3)),"=d"(*(s.where+2)):"a"(code));
+
+ s.vendor[16] = '\0';
+
+ printf("Vendor ID : %s\n\n", (s.vendor+4));
+
+}
--
1.7.7
From c36899d742b91c26c7855f7bac4f35746d818622 Mon Sep 17 00:00:00 2001
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sun, 21 Apr 2013 02:18:44 +0530
Subject: [PATCH 2/3] Unit test for checking VMX capabilities
---
config-x86-common.mak | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/config-x86-common.mak b/config-x86-common.mak
index 1f0f1ba..df2a42e 100644
--- a/config-x86-common.mak
+++ b/config-x86-common.mak
@@ -31,7 +31,7 @@ FLATLIBS = lib/libcflat.a $(libgcc)
tests-common = $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \
$(TEST_DIR)/smptest.flat $(TEST_DIR)/port80.flat \
- $(TEST_DIR)/realmode.flat $(TEST_DIR)/msr.flat \
+ $(TEST_DIR)/realmode.flat $(TEST_DIR)/msr.flat $(TEST_DIR)/vmx_test.flat \
$(TEST_DIR)/hypercall.flat $(TEST_DIR)/sieve.flat \
$(TEST_DIR)/kvmclock_test.flat $(TEST_DIR)/eventinj.flat \
$(TEST_DIR)/s3.flat $(TEST_DIR)/pmu.flat \
@@ -79,6 +79,8 @@ $(TEST_DIR)/realmode.o: bits = 32
$(TEST_DIR)/msr.elf: $(cstart.o) $(TEST_DIR)/msr.o
+$(TEST_DIR)/vmx_test.elf: $(cstart.o) $(TEST_DIR)/vmx_test.o
+
$(TEST_DIR)/idt_test.elf: $(cstart.o) $(TEST_DIR)/idt_test.o
$(TEST_DIR)/xsave.elf: $(cstart.o) $(TEST_DIR)/xsave.o
--
1.7.7
From 1d61a82ec1525c087cbd205fb8ea4576cd30b04b Mon Sep 17 00:00:00 2001
From: Mohit Dhingra <mohitdhingras@gmail.com>
Date: Sun, 21 Apr 2013 02:18:53 +0530
Subject: [PATCH 3/3] Unit test for checking VMX capabilities
---
x86/unittests.cfg | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index 5e08c55..1a65a14 100644
--- a/x86/unittests.cfg
+++ b/x86/unittests.cfg
@@ -63,6 +63,9 @@ file = hypercall.flat
[idt_test]
file = idt_test.flat
+[vmx_test]
+file = vmx_test.flat
+
[msr]
file = msr.flat
@@ -101,4 +104,4 @@ extra_params = --append "10000000 `date +%s`"
[pcid]
file = pcid.flat
-extra_params = -cpu qemu64,+pcid
\ No newline at end of file
+extra_params = -cpu qemu64,+pcid
--
1.7.7
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-20 21:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-13 18:24 Interested in working for GSoC project Mohit Dhingra
2013-04-14 8:18 ` Jan Kiszka
2013-04-14 10:29 ` Kashyap Chamarthy
2013-04-20 21:01 ` Mohit Dhingra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox