[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
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"
<snip>
/* 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
