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/
Home Products Support Community News


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 13:27:04 +0200
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 24 Jan 2006 11:35:42 +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=YZJZ8ljHCqeQXgdCS/htgT21yFajNH20B7q2KgPTy4GFwWzHF3UPLKkQupJBK7PSgkITw9HeJXds7Yn4qb6o+MsfkUNbKIOM8I2ueQJa+bp209cT1OZ40PgbyuLvh/slwa01wxWNtN3vYihWbd2lSnA8WqE92ZFor54Zm4aZuC0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <60c562438f7299b8b178aa9b70cd6997@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

First, thanks Keir for your answer.

>The point of paravirtualization is that such instructions are replaced
>with explicit traps to the hypervisor in the OS.
>Emulation of the raw instruction is not required.

I had thought again about your answer and after probing the code
and IA32 manuals I am not sure I understood you fully and correctly.

I tried to look for such privileged instructions in the guest OS code
(for IA32)
which are replaced with explicit traps to the hypervisor and didn't find.

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
and could not find there a mechanism which will trap to the hypervisor;maybe
I had totally missed the point?)



On 1/12/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> On 12 Jan 2006, at 09:27, Ian Brown wrote:
> > So I tried to find where in the Xen-3.0 code it is done.
> > I saw in vmx.c the vmx_vmexit_do_hlt() method ,which is called
> > when "HLT" is performed,  but this is relevant when running a
> > platform with VT-x.
> > I am looking for tracing where this handling or modifying of
> > the HLT instruction is done in a usual x386 (non-VTX) processor.
> >
> > Can anybody please point where in the code of Xen 3.0 this is done
> > (for x86 processors)?
> The point of paravirtualizetion is that such instructions are replaced
> with explicit traps to the hypervisor in the OS. Emulation of the raw
> instruction is not required.
> In fact we do emulate some privileged instructions, just not HLT.
>   -- Keir

Xen-devel mailing list