Re: [Xen-devel] Paravirtualization of the "HLT" instruction (for example) on x386

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Mark Ryden wrote:

> > Furthermore, some instructions *have* to be paravirtualised because
> > they do not trap
> >    
> So all the instances of such instructions which don't trap and are
> problemtaic in some sense , under the linux-xen0 and linux-xenU, are 
> replaced ?  Did I get it right ?
>  
Yes, a very thorough explaination of this all is available here:

http://www.cs.nps.navy.mil/people/faculty/irvine/publications/2000/VMM-usenix00-0611.pdf

Regards,

Anthony Liguori

> Mark
>
>
>
> On 1/24/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
>  
>
> > On 24 Jan 2006, at 11:27, Ian Brown wrote:
> >
> >    
> >
> > > I know that CLTS and WBINVD instructions, for example , should cause
> > > #GP(0) if run from CPL which is not 0; but grepping for an asm
> > > instruction
> > > which calls CLTS or WBINVD under the sparse tree gives no results.
> > >
> > > Can you give one example for such an instruction which cause a trap
> > > to the hypervisor when run in a guest OS and where in the code it
> > > causes
> > > such a trap ?
> > >
> > > (As far as I understand,if we try to issue a privilege instruction from
> > > CPL1 we should get a #GP(0) and reach the general protection
> > > handler in sparse/arch/xen/i386/kernel/traps.c ,
> > > do_general_protection().
> > >
> > > But I had looked at do_general_protection() in
> > > sparse/arch/xen/i386/kernel/traps.c
> > > and could not find there a mechanism which will trap to the
> > > hypervisor;maybe
> > > I had totally missed the point?)
> > >      
> > The main entry point for GPFs is in the hypervisor at
> > do_general_protection() in xen/arch/x86/traps.c. For certain privileged
> > instructions we perform emulation (see emulate_privileged_op() in the
> > same Xen source file). We emulate both CLTS and WBINVD for example.
> > GPFs that are not handled by Xen are indeed then passed to the guest
> > and will end up in the function you mentioned in your email.
> >
> > However, we also have paravirtualised versions of both those
> > instructions (for example, CLTS is equivalent to the hypercall
> > fpu_taskswitch(0)).
> >
> > Furthermore, some instructions *have* to be paravirtualised because
> > they do not trap (for example, POPF where the restored EFLAGS has a
> > different Interrupt-Enable flag value from current EFLAGS).
> >
> >  -- Keir
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> >    
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>  

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