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: Mon, 02 Apr 2007 13:54:05 -0500
Cc: "Yu, Wilfred" <wilfred.yu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Mon, 02 Apr 2007 11:53:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1175539525.9276.5.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.10 (X11/20070307)
Kamble, Nitin A wrote:
On Fri, 2007-03-30 at 15:11 -0700, Anthony Liguori wrote:

set_cr0 is returning 1 though which should increment eip to the next
instruction.

I'm a bit perplexed about my eip now and also why your eip is still 0. It should be the instruction following the mov cr0.

Regards,

Anthony Liguori


Hi Anthony,
I don't see any code doing context save/restore like vmx_world_save , vmx_world_restore in the current code for the hyperviser based emulator.

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?

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?

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.

Regards,

Anthony Liguori

The code would need vmx_world_save/restore in the code path before returning to vmx_asm_vmexit_handler from vmx_vmexit_handler.
Without that I don't see it can emulate any instructions.

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