From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH][RFC] Emulating real mode with x86_emulate Date: Fri, 30 Mar 2007 14:00:04 -0500 Message-ID: <460D5E34.2080803@us.ibm.com> References: <4607074E.1030807@us.ibm.com> <1175203075.27076.17.camel@lnitindesktop.sc.intel.com> <460C4AAE.5020707@us.ibm.com> <1175212362.27076.32.camel@lnitindesktop.sc.intel.com> <460C55BD.5050202@us.ibm.com> <1175216381.27076.39.camel@lnitindesktop.sc.intel.com> <1175221214.27076.43.camel@lnitindesktop.sc.intel.com> <460C8207.8000604@us.ibm.com> <1175280781.32115.13.camel@lnitindesktop.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1175280781.32115.13.camel@lnitindesktop.sc.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Kamble, Nitin A" Cc: "Yu, Wilfred" , xen-devel@lists.xensource.com, Keir Fraser , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org 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 >> >> > > 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. My tip is 14462:3fd9b0c71b8c and in hvmloader.c, there is: asm( " .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. Regards, 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, > 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 >> >