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

["Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>]

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?

Thanks & Regards,
Nitin
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.
>
> 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