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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 17:13:15 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Bastian Blank <bastian@xxxxxxxxxxxx>, "544145@xxxxxxxxxxxxxxx" <544145@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Nov 2009 09:13:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1258994658.7590.80.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpsXEUJGuQHEGgOTMCbfxDv4F8Y/gAA/ktb
Thread-topic: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel
User-agent: Microsoft-Entourage/12.23.0.091001
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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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