On Thu, 2007年03月29日 at 22:20 -0500, Anthony Liguori wrote:

> ... 
> (XEN) hvm.c:446:d2 Triple fault on VCPU0 - invoking HVM system reset.
The Triple fault you're seeing here is terribly curious. Also the 
"deadbeef" output. Just to sanity check, I threw the following printk 
in vmcs.c

Anthony,
To me the tripple fault makes sense.

Your patch enables emulation only when "emulating" is set to 1.


void arch_vmx_do_resume(struct vcpu *v)
{
if ( v->arch.hvm_vmx.active_cpu == smp_processor_id() )
@@ -508,7 +644,11 @@ void arch_vmx_do_resume(struct vcpu *v)
}

hvm_do_resume(v);
- reset_stack_and_jump(vmx_asm_do_vmentry);
+
+ if (v->arch.hvm_vmx.emulating)
+ vmx_do_emulate(v);
+ else
+ reset_stack_and_jump(vmx_asm_do_vmentry);
}


And it is turned on only when guest (hvmloader) sets up CR0.

-static int vmx_set_cr0(unsigned long value)
+int vmx_set_cr0(unsigned long value)
{
struct vcpu *v = current;
unsigned long mfn;
@@ -1982,13 +1982,29 @@ static int vmx_set_cr0(unsigned long val
}
}

- if ( vmx_assist(v, VMX_ASSIST_INVOKE) )
+ if ( v->arch.hvm_vcpu.emulate_realmode )
+ {
+ eip = __vmread(GUEST_RIP);
+ HVM_DBG_LOG(DBG_LEVEL_1,
+ "Transfering control to x86_emulate %%eip 0x%lx\n", eip);
+ v->arch.hvm_vmx.emulating = 1;
+ return 1;
+ }
+ else if ( vmx_assist(v, VMX_ASSIST_INVOKE) )
{

And I don't see any code in the hvmloader for setting cr0 before returning from the main.

So the code flow is returning from main, which is causing the tripple fault.

I observe the vmx_do_emulate is never getting called.

I think set cr0 instruction is needed just after the emulate_realmode hypercall in the hvmloader code.

Have you added more code lateron after sending the patch out?

 while (!hypercall_preempt_check()) {
+ printk("eip = 0x%x\n", regs->eip);
 if (x86_emulate(&ctxt, &em_ops)) {
And I get the following output with a FC5 guest:
(XEN) 
hvmop_emulate_realmode 
(XEN) guest requests real mode 
emulation 
(XEN) foo 
221 
(XEN) eip = 
0xd338d 
(XEN) eip = 
0xd338e 
(XEN) eip = 
0xffbf0000 
(XEN) failed to emulate instruction at %eip = 
0xd338d 
(XEN) domain_crash_sync called from 
vmcs.c:625 
(XEN) Domain 1 (vcpu#0) crashed on 
cpu#0: 
(XEN) ----[ Xen-3.0-unstable x86_32 debug=n Not tainted 
]---- 
(XEN) CPU: 
0 
(XEN) EIP: 
0010:[<000d338d>] 
(XEN) EFLAGS: 00000002 CONTEXT: 
hvm 
(XEN) eax: 00000076 ebx: 000d7324 ecx: 000d7324 edx: 
000000e9 
(XEN) esi: 000d4e54 edi: 000d3380 ebp: 000d72a8 esp: 
000d72a8 
(XEN) cr0: 00050032 cr4: 00000651 cr3: 00000000 cr2: 
00000000 
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0018 cs: 0010 
So, perhaps it's the guest you're using? Clearly, we're running in 
x86_emulate and hitting a 16 bit instruction we can't handle. N.B. the 
printk in the error path for x86_emulate is wrong. I should be looking 
at regs->eip, not GUEST_RIP since that wouldn't have been updated again.
Regards,
Anthony Liguori

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel