[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate

Kamble, Nitin A wrote:
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

  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)

-    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.

My tip is 14462:3fd9b0c71b8c and in hvmloader.c, there is:

   "    .text                       \n"
   "    .globl _start               \n"
   "_start:                         \n"
   /* C runtime kickoff. */
   "    cld                         \n"
   "    cli                         \n"
   "    movl $stack_top,%esp        \n"
   "    movl %esp,%ebp              \n"
   "    call main                   \n"
   /* Relocate real-mode trampoline to 0x0. */
   "    mov  $trampoline_start,%esi \n"
   "    xor  %edi,%edi              \n"
   "    mov  $trampoline_end,%ecx   \n"
   "    sub  %esi,%ecx              \n"
   "    rep  movsb                  \n"
   /* Enter real mode, reload all segment registers and IDT. */
   "    ljmp $0x8,$0x0              \n"
   "trampoline_start: .code16       \n"
   "    mov  %eax,%cr0              \n"

That change was pretty recent so unless it was reverted it should Just Work.


Anthony Liguori

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?

Thanks & Regards,
Open Source Technology Center, Intel Corporation.
The mind is like a parachute; it works much better when it's open.

     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.


Anthony Liguori

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.