[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: Mark Ryden <markryde@xxxxxxxxx>
  • Date: Sat, 28 Jan 2006 17:41:10 +0200
  • Cc: Ian Brown <ianbrn@xxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 28 Jan 2006 15:50:22 +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=CTPCNqsARShiotn3YoAQjiCoXZQYjE6WSYna/JzVUnzQmKPu1yzzlFJMUQ1EuHnXS9fheBUzho7YAID0qjW3sMcmtfsIXIJvmQ30Swq5VftUnxox4OH/mbaO5Czniy8r7aazG+BfrtGw23yg7wzXNK/pSvxNGL6C8CX1Dd+imls=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

>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 ?

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


 


Rackspace

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