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

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

signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

WARNING - OLD ARCHIVES

xen-devel

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