WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Paravirtualization of the "HLT" instruction (for example) on x386
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9aeefb8a24491cfdcda09e814f95fe81@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <d0383f90601120127g5994eedal71bac2a01fce5e87@xxxxxxxxxxxxxx> <60c562438f7299b8b178aa9b70cd6997@xxxxxxxxxxxx> <d0383f90601240327i56a8414cua2c75a0bab3c342e@xxxxxxxxxxxxxx> <9aeefb8a24491cfdcda09e814f95fe81@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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