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

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

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

Also calling the x86_emulate() to emulate multiple instructions from vmx_do_resume() will block the physical cpu from other vcpus. 
I think we discussed the approach of using the non-root context for for emulator within the Xen. Or did I misunderstanding it?

>     Regards,
>     
>     Anthony Liguori
>

Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation.
-------------------------------------------------------------------------
The mind is like a parachute; it works much better when it's open.

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

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