Hello, I tried to write a piece of code to start vmx. This code is directly interacting with cpu instead of with virtual cpu as in xen. But every time I call vmxon, a GP exception happens. Could anybody help me on this? The following is the context 1. After booting up to the program, I disable A20M. 2. allocate a 4kb-aligned vmxon region and calculate its physical address. 3. setup identity page table and enter protected page mode. In this step I also set x86_cr0_ne ( cr0.bit5) 4. call start_vmx. This start_vmx function is similar to the one in xen3.1.0 a. test cpuid with eax = 1. ecx.vmxe(bit5) is 1. b. Test IA32_FEATURE_CONTROL_MSR, result is 0x05, so bit 0 and bit 2 are both 1. c. Set cr4.vmxe (bit13) to 1 d. Call vmx_init_vmcs_config(). This function is the same as in xen3.1.0. e. Call vmxon, passing it the physical adderss calculated in step2, using the same op-code as xen f. stop vmx by calling vmxoff. Using "while(1)", I traced and found the GP exception happened in step 4.e.>From Intel Software Development Manual 2B, I get the followingconditions to throw a GP. IF (CPL > 0) or (in A20M mode) or (the values of CR0 and CR4 are supported in VMX operation) or (bit 0 (lock bit) of IA32_FEATURE_CONTROL MSR is clear) or (bit 2 of IA32_FEATURE_CONTROL MSR is clear) THEN #GP(0); I checked the conditions and found none of them was violated. The results are as follows CR0 : 0x80000031 IA32_VMX_CR0_FIXED0: 0x80000021 IA32_VMX_CR0_FIXED1: 0xFFFFFFFF CR4 : 0x2250 IA32_VMX_CR4_FIXED0: 0x2000 IA32_VMX_CR4_FIXED1: 0x27FF IA32_VMX_BASIC_MSR is 001A 0400 0000 0007 The revision ID 0x07 is assigned to the corresponding field in vmxon region in the step 4.d IA32_FEATURE_CONTROL is 0x05 My PC has a 32 bit, VT-support multi-core CPU. I use only the BSP and haven''t dealt with multi-cpu wake-up. Best regards, Hu Jia Yi Ext: 20430 Tel: 65-67510430 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
How early do you run? Are you really confident that you disabled A20M? A simple test would confirm this (check whether address 2MB aliases with 1MB). -- Keir On 11/1/08 06:46, "Hu Jia Yi" <jyhu@asmpt.com> wrote:> Hello, I tried to write a piece of code to start vmx. > This code is directly interacting with cpu instead of with virtual cpu as in > xen. > But every time I call vmxon, a GP exception happens. > > Could anybody help me on this? The following is the context > > 1. After booting up to the program, I disable A20M. > 2. allocate a 4kb-aligned vmxon region and calculate its physical address. > 3. setup identity page table and enter protected page mode. In this step I > also set x86_cr0_ne ( cr0.bit5) > 4. call start_vmx. This start_vmx function is similar to the one in xen3.1.0 >> 1. test cpuid with eax = 1. ecx.vmxe(bit5) is 1. >> 2. Test IA32_FEATURE_CONTROL_MSR, result is 0x05, so bit 0 and bit 2 are both >> 1. >> 3. Set cr4.vmxe (bit13) to 1 >> 4. Call vmx_init_vmcs_config(). This function is the same as in xen3.1.0. >> 5. Call vmxon, passing it the physical adderss calculated in step2, using the >> same op-code as xen > f. stop vmx by calling vmxoff. > > Using ³while(1)², I traced and found the GP exception happened in step 4.e. > From Intel Software Development Manual 2B, I get the following conditions to > throw a GP. > > IF (CPL > 0) or (in A20M mode) or > (the values of CR0 and CR4 are supported in VMX operation) or > (bit 0 (lock bit) of IA32_FEATURE_CONTROL MSR is clear) or > (bit 2 of IA32_FEATURE_CONTROL MSR is clear) > THEN #GP(0); > > I checked the conditions and found none of them was violated. > The results are as follows > > CR0 : 0x80000031 > IA32_VMX_CR0_FIXED0: 0x80000021 > IA32_VMX_CR0_FIXED1: 0xFFFFFFFF > > CR4 : 0x2250 > IA32_VMX_CR4_FIXED0: 0x2000 > IA32_VMX_CR4_FIXED1: 0x27FF > > IA32_VMX_BASIC_MSR is 001A 0400 0000 0007 > The revision ID 0x07 is assigned to the corresponding field in vmxon region in > the step 4.d > > IA32_FEATURE_CONTROL is 0x05 > > My PC has a 32 bit, VT-support multi-core CPU. > I use only the BSP and haven¹t dealt with multi-cpu wake-up. > > Best regards, > Hu Jia Yi > Ext: 20430 > Tel: 65-67510430 > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I ran two tests. One was a program after MS-DOS boot-up; the other was
using GRUB to boot the code and call start_vmx.
Both led to GP exception.
I haven''t really checked A20M. but I use the following code to disable
it.
_disable_A20:
push ax
in al, 0x92
and al, 0x0fd
out 0x92, al
pop ax
retn
Best regards,
Hu Jia Yi
Ext: 20430
Tel: 65-67510430
-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
Sent: Friday, January 11, 2008 4:41 PM
To: Hu Jia Yi; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GP exception on vmxon
How early do you run? Are you really confident that you disabled A20M? A
simple test would confirm this (check whether address 2MB aliases with
1MB).
-- Keir
On 11/1/08 06:46, "Hu Jia Yi" <jyhu@asmpt.com> wrote:
Hello, I tried to write a piece of code to start vmx.
This code is directly interacting with cpu instead of with virtual cpu
as in xen.
But every time I call vmxon, a GP exception happens.
Could anybody help me on this? The following is the context
1. After booting up to the program, I disable A20M.
2. allocate a 4kb-aligned vmxon region and calculate its physical
address.
3. setup identity page table and enter protected page mode. In this
step I also set x86_cr0_ne ( cr0.bit5)
4. call start_vmx. This start_vmx function is similar to the one in
xen3.1.0
1. test cpuid with eax = 1. ecx.vmxe(bit5) is 1.
2. Test IA32_FEATURE_CONTROL_MSR, result is 0x05, so bit 0 and bit
2 are both 1.
3. Set cr4.vmxe (bit13) to 1
4. Call vmx_init_vmcs_config(). This function is the same as in
xen3.1.0.
5. Call vmxon, passing it the physical adderss calculated in step2,
using the same op-code as xen
f. stop vmx by calling vmxoff.
Using "while(1)", I traced and found the GP exception happened in step
4.e. >From Intel Software Development Manual 2B, I get the following
conditions to throw a GP.
IF (CPL > 0) or (in A20M mode) or
(the values of CR0 and CR4 are supported in VMX operation) or
(bit 0 (lock bit) of IA32_FEATURE_CONTROL MSR is clear) or
(bit 2 of IA32_FEATURE_CONTROL MSR is clear)
THEN #GP(0);
I checked the conditions and found none of them was violated.
The results are as follows
CR0 : 0x80000031
IA32_VMX_CR0_FIXED0: 0x80000021
IA32_VMX_CR0_FIXED1: 0xFFFFFFFF
CR4 : 0x2250
IA32_VMX_CR4_FIXED0: 0x2000
IA32_VMX_CR4_FIXED1: 0x27FF
IA32_VMX_BASIC_MSR is 001A 0400 0000 0007
The revision ID 0x07 is assigned to the corresponding field in vmxon
region in the step 4.d
IA32_FEATURE_CONTROL is 0x05
My PC has a 32 bit, VT-support multi-core CPU.
I use only the BSP and haven''t dealt with multi-cpu wake-up.
Best regards,
Hu Jia Yi
Ext: 20430
Tel: 65-67510430
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
In linux environment (FC7), the definition of vmxon and its vmxon region
is the same as in xen.
In MS-DOS, I have to use 16 bit vmxon operand op-code, as follows
;compiled using NASM
%define VMXON_OPCODE db 0xf3, 0xf, 0xc7 ;same as in xen
%define MODRM_BX_SI_06 db 0x30 ;the physical
address is in [bx+si] ref: Intel SDM 2A Page2-6
;====================
;word vmxon(dword* p_vmcs)
;====================
_vmxon:
push bp
mov bp, sp
mov bx, [bp+4]
mov si, 0
VMXON_OPCODE
MODRM_BX_SI_06
;return value is in ax
ja .1
mov ax, 0 ;fail
jmp .2
.1:
mov ax, 1 ;success
pop bp
retn
in C file
int start_vmx()
{
int phy_vmcs[4] = {0,0,0,0}; /* to form 64bit operand and
phy_vmcs[0] is at the lowest address*/
...
phy_vmcs[0] = g_vmcs_phy_addr; /*g_vmcs_phy_addr is
the physical address calculated in real mode because the base is not
zero*/
return vmxon(phy_vmcs);
}
Best regards,
Hu Jia Yi
Ext: 20430
Tel: 65-67510430
-----Original Message-----
From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
Sent: Friday, January 11, 2008 4:41 PM
To: Hu Jia Yi; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GP exception on vmxon
How early do you run? Are you really confident that you disabled A20M? A
simple test would confirm this (check whether address 2MB aliases with
1MB).
-- Keir
On 11/1/08 06:46, "Hu Jia Yi" <jyhu@asmpt.com> wrote:
Hello, I tried to write a piece of code to start vmx.
This code is directly interacting with cpu instead of with virtual cpu
as in xen.
But every time I call vmxon, a GP exception happens.
Could anybody help me on this? The following is the context
1. After booting up to the program, I disable A20M.
2. allocate a 4kb-aligned vmxon region and calculate its physical
address.
3. setup identity page table and enter protected page mode. In this
step I also set x86_cr0_ne ( cr0.bit5)
4. call start_vmx. This start_vmx function is similar to the one in
xen3.1.0
1. test cpuid with eax = 1. ecx.vmxe(bit5) is 1.
2. Test IA32_FEATURE_CONTROL_MSR, result is 0x05, so bit 0 and bit
2 are both 1.
3. Set cr4.vmxe (bit13) to 1
4. Call vmx_init_vmcs_config(). This function is the same as in
xen3.1.0.
5. Call vmxon, passing it the physical adderss calculated in step2,
using the same op-code as xen
f. stop vmx by calling vmxoff.
Using "while(1)", I traced and found the GP exception happened in step
4.e. >From Intel Software Development Manual 2B, I get the following
conditions to throw a GP.
IF (CPL > 0) or (in A20M mode) or
(the values of CR0 and CR4 are supported in VMX operation) or
(bit 0 (lock bit) of IA32_FEATURE_CONTROL MSR is clear) or
(bit 2 of IA32_FEATURE_CONTROL MSR is clear)
THEN #GP(0);
I checked the conditions and found none of them was violated.
The results are as follows
CR0 : 0x80000031
IA32_VMX_CR0_FIXED0: 0x80000021
IA32_VMX_CR0_FIXED1: 0xFFFFFFFF
CR4 : 0x2250
IA32_VMX_CR4_FIXED0: 0x2000
IA32_VMX_CR4_FIXED1: 0x27FF
IA32_VMX_BASIC_MSR is 001A 0400 0000 0007
The revision ID 0x07 is assigned to the corresponding field in vmxon
region in the step 4.d
IA32_FEATURE_CONTROL is 0x05
My PC has a 32 bit, VT-support multi-core CPU.
I use only the BSP and haven''t dealt with multi-cpu wake-up.
Best regards,
Hu Jia Yi
Ext: 20430
Tel: 65-67510430
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
If you run in MS-DOS context you¹re probably in real mode, and hence VMXON will #GP? -- Keir On 11/1/08 09:25, "Hu Jia Yi" <jyhu@asmpt.com> wrote:> In linux environment (FC7), the definition of vmxon and its vmxon region is > the same as in xen. > In MS-DOS, I have to use 16 bit vmxon operand op-code, as follows > > ;compiled using NASM > %define VMXON_OPCODE db 0xf3, 0xf, 0xc7 ;same as in xen > %define MODRM_BX_SI_06 db 0x30 ;the physical address is > in [bx+si] ref: Intel SDM 2A Page2-6 > > ;====================> ;word vmxon(dword* p_vmcs) > ;====================> _vmxon: > push bp > mov bp, sp > > mov bx, [bp+4] > mov si, 0 > > VMXON_OPCODE > MODRM_BX_SI_06 > > ;return value is in ax > ja .1 > mov ax, 0 ;fail > jmp .2 > .1: > mov ax, 1 ;success > > pop bp > retn > > in C file > > int start_vmx() > { > int phy_vmcs[4] = {0,0,0,0}; /* to form 64bit operand and > phy_vmcs[0] is at the lowest address*/ > > phy_vmcs[0] = g_vmcs_phy_addr; /*g_vmcs_phy_addr is the > physical address calculated in real mode because the base is not zero*/ > > return vmxon(phy_vmcs); > } > > > > > Best regards, > Hu Jia Yi > Ext: 20430 > Tel: 65-67510430 > -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Friday, January 11, 2008 4:41 PM > To: Hu Jia Yi; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] GP exception on vmxon > > How early do you run? Are you really confident that you disabled A20M? A > simple test would confirm this (check whether address 2MB aliases with 1MB). > > -- Keir > > On 11/1/08 06:46, "Hu Jia Yi" <jyhu@asmpt.com> wrote: > Hello, I tried to write a piece of code to start vmx. > This code is directly interacting with cpu instead of with virtual cpu as in > xen. > But every time I call vmxon, a GP exception happens. > > Could anybody help me on this? The following is the context > > 1. After booting up to the program, I disable A20M. > 2. allocate a 4kb-aligned vmxon region and calculate its physical address. > 3. setup identity page table and enter protected page mode. In this step I > also set x86_cr0_ne ( cr0.bit5) > 4. call start_vmx. This start_vmx function is similar to the one in > xen3.1.0 > 1. test cpuid with eax = 1. ecx.vmxe(bit5) is 1. > 2. Test IA32_FEATURE_CONTROL_MSR, result is 0x05, so bit 0 and bit 2 are > both 1. > 3. Set cr4.vmxe (bit13) to 1 > 4. Call vmx_init_vmcs_config(). This function is the same as in xen3.1.0. > 5. Call vmxon, passing it the physical adderss calculated in step2, using > the same op-code as xen > f. stop vmx by calling vmxoff. > > Using ³while(1)², I traced and found the GP exception happened in step 4.e. > From Intel Software Development Manual 2B, I get the following conditions to > throw a GP. > > IF (CPL > 0) or (in A20M mode) or > (the values of CR0 and CR4 are supported in VMX operation) or > (bit 0 (lock bit) of IA32_FEATURE_CONTROL MSR is clear) or > (bit 2 of IA32_FEATURE_CONTROL MSR is clear) > THEN #GP(0); > > I checked the conditions and found none of them was violated. > The results are as follows > > CR0 : 0x80000031 > IA32_VMX_CR0_FIXED0: 0x80000021 > IA32_VMX_CR0_FIXED1: 0xFFFFFFFF > > CR4 : 0x2250 > IA32_VMX_CR4_FIXED0: 0x2000 > IA32_VMX_CR4_FIXED1: 0x27FF > > IA32_VMX_BASIC_MSR is 001A 0400 0000 0007 > The revision ID 0x07 is assigned to the corresponding field in vmxon region in > the step 4.d > > IA32_FEATURE_CONTROL is 0x05 > > My PC has a 32 bit, VT-support multi-core CPU. > I use only the BSP and haven¹t dealt with multi-cpu wake-up. > > Best regards, > Hu Jia Yi > Ext: 20430 > Tel: 65-67510430 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel