From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH][RFC] Emulating real mode with x86_emulate Date: Mon, 02 Apr 2007 13:54:05 -0500 Message-ID: <4611514D.4090404@us.ibm.com> References: <4607074E.1030807@us.ibm.com> <1175203075.27076.17.camel@lnitindesktop.sc.intel.com> <460C4AAE.5020707@us.ibm.com> <1175212362.27076.32.camel@lnitindesktop.sc.intel.com> <460C55BD.5050202@us.ibm.com> <1175216381.27076.39.camel@lnitindesktop.sc.intel.com> <1175221214.27076.43.camel@lnitindesktop.sc.intel.com> <460C8207.8000604@us.ibm.com> <1175280781.32115.13.camel@lnitindesktop.sc.intel.com> <460D5E34.2080803@us.ibm.com> <1175288913.32115.20.camel@lnitindesktop.sc.intel.com> <1175289886.32115.26.camel@lnitindesktop.sc.intel.com> <460D8B1B.6020308@us.ibm.com> <1175539525.9276.5.camel@lnitindesktop.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1175539525.9276.5.camel@lnitindesktop.sc.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Kamble, Nitin A" Cc: "Yu, Wilfred" , xen-devel@lists.xensource.com, Keir Fraser , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org 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. >