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. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
