[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.