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@xxxxxxxxxxxx] 
Sent: Friday, January 11, 2008
4:41 PM
To: Hu Jia Yi; xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel