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

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

  • To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • From: Ian Brown <ianbrn@xxxxxxxxx>
  • Date: Tue, 24 Jan 2006 14:24:28 +0200
  • Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Jan 2006 12:33:05 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p1/zsLalIfNpexUAV+jCeYcUu6NPBdl4GdnKya6OURTLGhq82+f1g22obl4/SD+OO9khULWpmlMs0oBcxAm/EdFSpRlPkyKiJ4fAa3sgV2brojTEm7sAZyzMIt8B/bphGKfQwBc6eHMLeKwZoufAkoNVX9G9KE/CV9KV81zWCuo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>


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)


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



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