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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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