[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel



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@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
 ENDPATCH(xen_sysret32)
 RELOC(xen_sysret32, 1b+1)



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.