From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jan Beulich <JBeulich@novell.com>
Cc: "544145@bugs.debian.org" <544145@bugs.debian.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Bastian Blank <bastian@waldi.eu.org>
Subject: Re: Crash with paravirt-ops 2.6.31.6 kernel
Date: Wed, 25 Nov 2009 13:24:16 -0800 [thread overview]
Message-ID: <4B0DA080.7030904@goop.org> (raw)
In-Reply-To: <4B0D13850200007800021FC6@vpn.id2.novell.com>
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?
J
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@citrix.com>
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
ENDPATCH(xen_sysret32)
RELOC(xen_sysret32, 1b+1)
next prev parent reply other threads:[~2009-11-25 21:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 19:04 Crash with paravirt-ops 2.6.31.6 kernel William Pitcock
2009-11-18 14:45 ` Konrad Rzeszutek Wilk
2009-11-19 8:21 ` William Pitcock
2009-11-19 17:31 ` Konrad Rzeszutek Wilk
2009-11-20 4:12 ` Jeremy Fitzhardinge
2009-11-22 9:54 ` Bastian Blank
2009-11-23 15:25 ` Ian Campbell
2009-11-23 16:31 ` Bug#544145: [Xen-devel] " Bastian Blank
2009-11-23 16:42 ` Bug#544145: " Ian Campbell
2009-11-23 17:23 ` Bug#544145: [Xen-devel] " Bastian Blank
2009-11-24 0:52 ` Bug#544145: " Jeremy Fitzhardinge
2009-11-23 16:31 ` Jan Beulich
2009-11-23 16:44 ` Ian Campbell
2009-11-23 17:13 ` Keir Fraser
2009-11-23 17:17 ` Ian Campbell
2009-11-25 10:22 ` Jan Beulich
2009-11-25 21:24 ` Jeremy Fitzhardinge [this message]
2009-11-26 7:35 ` Jan Beulich
2009-11-26 9:57 ` Ian Campbell
2009-11-24 0:39 ` Jeremy Fitzhardinge
2009-11-24 9:48 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B0DA080.7030904@goop.org \
--to=jeremy@goop.org \
--cc=544145@bugs.debian.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@novell.com \
--cc=bastian@waldi.eu.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.