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
[Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit).
On 26/07/2011 22:40, "Andrew Lutomirski" <luto@xxxxxxx> wrote:
> If we go into the iret patch (via auditing, for example), then the
> FIXUP_TOP_OF_STACK macro does movq $__USER_CS,CS+\offset(%rsp), which
> (unless it's buggy) writes __USER_CS into the appropriate spot.
> So I don't see what part of the entry path needs patching.
You'll get Xen's flat CS values loaded if Xen uses SYSRET to return to guest
context. This will happen on return to guest userspace if the guest kernel
calls the iret hypercall specifying the VGCF_in_syscall flag. And that would
typically happen when returning to userspace after a syscall. So I guess the
typical user process will quickly end up using the Xen code selector rather
than Linux's own.
Xen-devel mailing list