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] Crash with paravirt-ops kernel

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Crash with paravirt-ops kernel
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Mon, 23 Nov 2009 17:17:54 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Blank <bastian@xxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Bastian, "544145@xxxxxxxxxxxxxxx" <544145@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Nov 2009 09:18:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C730732B.1648%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <C730732B.1648%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2009-11-23 at 17:13 +0000, Keir Fraser wrote:
> On 23/11/2009 16:44, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
> >> But this is not just the return-to-user-space path you're changing, but
> >> also the hypercall one. You certainly don't want an iret in that case.
> > 
> > Don't the hypercalls already always go via iret?
> > -        testw $TRAP_syscall,4(%rsp)
> > -        jz    iret_exit_to_guest
> > IOW if TRAP_syscall is not set (i.e. this is a hypercall not a syscall)
> > then exit via iret.
> I think not -- here TRAP_syscall means 'entered Xen via SYSCALL
> instruction', not 'entered to do a syscall'. TRAP_syscall should be set
> regardless of whether the SYSCALL instruction was executed by guest userland
> or guest kernel.

Oh yes, I was confused into thinking it was the same as VGCF_in_syscall
for some reason.

>  -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>