|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate
To: |
"Anthony Liguori" <aliguori@xxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate |
From: |
"Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> |
Date: |
Mon, 2 Apr 2007 16:52:25 -0700 |
Cc: |
"Yu, Wilfred" <wilfred.yu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> |
Delivery-date: |
Mon, 02 Apr 2007 16:51:21 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4611514D.4090404@xxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<4607074E.1030807@xxxxxxxxxx> <1175203075.27076.17.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <460C4AAE.5020707@xxxxxxxxxx> <1175212362.27076.32.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <460C55BD.5050202@xxxxxxxxxx> <1175216381.27076.39.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <1175221214.27076.43.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <460C8207.8000604@xxxxxxxxxx> <1175280781.32115.13.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <460D5E34.2080803@xxxxxxxxxx> <1175288913.32115.20.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <1175289886.32115.26.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <460D8B1B.6020308@xxxxxxxxxx> <1175539525.9276.5.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx> <4611514D.4090404@xxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
Acd1gfcrYHbZARDuRVyd6bkM/W933A== |
Thread-topic: |
[PATCH][RFC] Emulating real mode with x86_emulate |
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.
|
signature.asc
Description: This is a digitally signed message part
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|