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: Bug#544145: [Xen-devel] Crash with paravirt-ops kernel

On Mon, 2009-11-23 at 16:31 +0000, Bastian Blank wrote:
> On Mon, Nov 23, 2009 at 03:25:35PM +0000, Ian Campbell wrote:
> > We are attempting to return to the Linux defined __USER_CS32 (0x23)
> > which does not match the test for the Xen defined FLAT_USER_CS32
> > (0xe023) and therefore we hit the sysretq instead of the sysretl which
> > causes us to return with CS 0xe033 (FLAT_USER_CS64) instead of CS
> > 0xe023.
> Well, the problem is that this code ignores what the AMD spec stats:
> | Because a SYSCALLed operating system can be entered from either 64-bit
> | mode or compatibility mode, the corresponding SYSRET must know the mode
> | to which it must return. [...] In the service-routine entry point
> | code, a flag can be set indicating which type of SYSRET is needed upon
> | exiting the called routine.
> The code actually have to know if it was called from 64 or compatibility
> mode, not assume it.

Sounds correct. This is tricky for a hypervisor since we don't know the
mode of the guest user-mode processes which made the syscall. The guest
kernel does know this which is why I proposed an additional
VGCF_compat_mode flag.

> And it also say that you have to use sysret, and not iret.

I don't believe that is the case (the processor would have to carry some
state for the entire duration of a syscall for it to make any
difference). I think the spec simply assumes that an OS author would
want to use sysret if they used syscall.


Xen-devel mailing list