WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH][RFC] Emulating real mode with x86_emulate
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Tue, 03 Apr 2007 09:03:56 -0500
Cc: "Yu, Wilfred" <wilfred.yu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Tue, 03 Apr 2007 07:03:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1175557945.3593.16.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <1175557945.3593.16.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.10 (X11/20070307)
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


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



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