[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate
Hi Anthony, Keir,
As per your suggestion I added the SCHEDULE_SOFTIRQ in the set_cr0 path. And now I see the code path going to vmx_do_emulate() for emulation. I added the emulation code for ljmp and it is able to go forward 1 instruction now.
(XEN) HVM2: Loading Cirrus VGABIOS ...
(XEN) HVM2: Loading ACPI ...
(XEN) HVM2: Loading VMXAssist ... deadbeef
(XEN) HVM2: foo
(XEN) hvmop_emulate_realmode
(XEN) guest requests real mode emulation
(XEN) foo 221
(XEN) HVM2: Invoking ROMBIOS ...
(XEN) vmx_vmexit_handler called. eip = 0x0
(XEN) vmx_cr_access called eip=0x0
(XEN) mov_to_cr 0 called eip=0x0
(XEN) vmx_set_cr0 called eip=0x0
(XEN) Transfering -- control to x86_emulate eip 0x0
(XEN) cr access done: updating eip from eip = 0x0
(XEN) updated eip=0x3
(XEN) arch_vmx_do_resume: starting emulation
(XEN) vmx_do_emulate: hvm_store_cpu_guest_regs
(XEN) vmx_do_emulate: hypercall_preempt_check() = 0
(XEN) vmx_do_emulate: cs:eip = 0008:0003
(XEN) x86_emulate realmode: 0008:0003
(XEN) jmp far seg:offset (Xea) handled
(XEN) vmx_do_emulate: cs:eip = 0000:0008
(XEN) x86_emulate realmode: 0000:0008
(XEN) x86_emulate.c:2441:d2 Instr: 8e
(XEN) failed to emulate instruction at eip = 0x8
(XEN) domain_crash_sync called from vmcs.c:625
(XEN) Domain 2 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.0-unstable x86_32p debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) EIP: 0008:[<00000003>]
(XEN) EFLAGS: 00000046 CONTEXT: hvm
(XEN) eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000
(XEN) esi: 00000000 edi: 00000000 ebp: 00000000 esp: 00000000
(XEN) cr0: 00000000 cr4: 00000650 cr3: 00000000 cr2: 00000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0010 cs: 0008
I think getting more instruction emulated will be easy now. I will keep posted about the progress.
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation.
-------------------------------------------------------------------------
The mind is like a parachute; it works much better when it's open.
|
On Tue, 2007-04-03 at 07:03 -0700, Anthony Liguori wrote:
Kamble, Nitin A wrote:
> On Mon, 2007-04-02 at 11:54 -0700, Anthony Liguori wrote:
>> Before calling x86_emulate, we use hvm_store_cpu_guest_regs() to copy
>> the guest state into a regs struct (which happens to be the vcpu's reg
>> struct). This reads directly from the VMCS via vmread() so it should be
>> okay. I don't think a vmx_world_save/restore is actually needed
>> although perhaps I'm missing something?
> It may be ok to use hvm_store_cpu_guest_regs() for 1st few
> instructions, but I think it is not complete enough for emulator use.
What is missing? x86_emulate() only uses info in the regs (it calls out
to function pointers for special registers). The GP registers should be
kept up-to-date on vmexit and hvm_store_cpu_guest_regs() should sync the
remainder of the register state.
Is there a specific item you think is missing?
>>
>> > Also the function arch_vmx_do_resume() is called at the time of vcpu
>> > schedule, so it is not right to call the vmx_do_emulate() from there.
>>
>> Right, the idea was to have x86_emulate() be called instead of
>> vmentry(). I thought that being in the set_cr0 path would ensure that
>> we go through do_resume() again. Is this assumption incorrect?
> Yes, This assumption is not right. arch_vmx_do_resume() is assigned to
> schedule tail, so that the vcpu context is saved/restored when another
> vcpu is scheduled on the physical cpu.
Hrm, okay. Manually invoking the scheduler is probably a reasonable
place to start. It would be nice to clean things up though so that
wasn't necessary.
>>
>> I didn't want to just stick it in the set_cr0 path because we ought to
>> be able to pull the emulation loop into common code for SVM/VT and the
>> do_resume path seems like the only place where there's common place to
>> hook right now.
> I thought the emulator will be needed only for VMX; why is it needed
> for SVM?
As Keir mentioned, there are some corner cases where emulation is
needed. Also, there is some opportunity to simplify things by using the
emulator. For instance, instead of decoding a PIO instruction using the
info in the VMCS/VMCB (none of which is actually common to VT/SVM), we
may find that it is simpler to just call out to x86_emulate() and let it
decode and dispatch the PIO operation.
In fact, a large number of the exits can be handled in this way. I have
no clue if this would impact performance in a significant way but it
would definitely simplify things.
> Also calling the x86_emulate() to emulate multiple instructions from
> vmx_do_resume() will block the physical cpu from other vcpus.
That's what the hypercall_preempt_check() is for.
> I think we discussed the approach of using the non-root context for
> for emulator within the Xen. Or did I misunderstanding it?
We discussed quite a few approaches :-) I thought we settled on doing
the emulation within Xen. I'm not sure what would be gained from a
non-root context other than better security assurances.
Regards,
Anthony Liguori
>> 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
|
