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: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Crash with paravirt-ops kernel
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 25 Nov 2009 13:24:16 -0800
Cc: "544145@xxxxxxxxxxxxxxx" <544145@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Bastian Blank <bastian@xxxxxxxxxxxx>
Delivery-date: Wed, 25 Nov 2009 13:24:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B0D13850200007800021FC6@xxxxxxxxxxxxxxxxxx>
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>
References: <28846609.721258484676784.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx> <20091122095403.GA1496@xxxxxxxxxxxxxxxxxxxxxxx> <1258989935.7590.52.camel@xxxxxxxxxxxxxxxxxxxxxx> <4B0AC6FA0200007800021812@xxxxxxxxxxxxxxxxxx> <1258994658.7590.80.camel@xxxxxxxxxxxxxxxxxxxxxx> <4B0D13850200007800021FC6@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
On 11/25/09 02:22, Jan Beulich wrote:
> Okay, I think I spotted the relevant difference: 2.6.18 and forward ports
> set VGCF_in_syscall only when returning from 64-bit system calls (through
> ret_from_sys_call) - 32-bit syscalls (regardless of the entry path taken)
> return through int_ret_from_sys_call. 32-bit guest kernels shouldn't be
> affected by this, as compat mode returns from the hypervisor
> (compat_restore_all_guest) always use iret.

I think dropping the VCGF_in_syscall flag is the simplest possible fix
then.  There doesn't seem to be a huge benefit to using sysret in this
case.  Does this look OK?


Subject: [PATCH] xen: use iret for return from 64b kernel to 32b usermode

If Xen wants to return to a 32b usermode with sysret it must use the
right form.  When using VCGF_in_syscall to trigger this, it looks at
the code segment and does a 32b sysret if it is FLAT_USER_CS32.
However, this is different from __USER32_CS, so it fails to return
properly if we use the normal Linux segment.

So avoid the whole mess by dropping VCGF_in_syscall and simply use
plain iret to return to usermode.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>

diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 02f496a..f681d55 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -96,7 +96,7 @@ ENTRY(xen_sysret32)
        pushq $__USER32_CS
        pushq %rcx
-       pushq $VGCF_in_syscall
+       pushq $0
 1:     jmp hypercall_iret
 RELOC(xen_sysret32, 1b+1)

Xen-devel mailing list

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