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

[Ian Brown <ianbrn@xxxxxxxxx>]

Hello,

Thanks for your answer in such a short time !

I am aware of emulate_privileged_op() in traps.c and also of the
emulation of both CLTS and WBINVD in this method.

you said :
>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.

I am not sure about something regarding "are indeed then passed to the guest":
suppose a guest OS, running in ring 1, issues a privileged instruction (namely,
an instruction which causes #GP(0) since it was issued in CPL1 ).
I don't know if it is possible at all since as I understand such
instructions were replaced in the guest OS code. But let's say it's
possible, the
"passed to the guest" is the point I am trying to get at.

In such a case, what happens ? there is a #GP(0) of course, but who
handles it in the first place ? is it the OS in ring 0 (with it's
do_general_protection() method in this case ? )
? or is it the OS in ring 1, which also
have do_general_protection() method ?

and by
>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.

you mean that GPFs that occurred in ring 1 will be handled at the first
place by the guest ? (or ,what seems to me more unlikely, first by ring0
and then somehow "passed" to the guest)

Regards,
IB




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