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


[Xen-devel] Switching to user mode from domU kernel

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Switching to user mode from domU kernel
From: Trammell Hudson <hudson@xxxxxxxxxxxxxx>
Date: Sun, 30 Sep 2007 16:11:43 -0400
Delivery-date: Sun, 30 Sep 2007 13:12:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.10i
I'm having trouble switching into user mode with my domU kernel --
everytime I call __HYPERVISOR_iret, the hypervisor calls into my
kernel via the registered callback handler.  None of the bits in
the event channel pending arrays are set.  If I return via the
iret call, the hypervisor immediately calls back into the handler.
The user RIP never changes, so it is clearly not making forward

The stackframe should be correctly setup with the flags, rip, cs,
rflags, rsp, and ss values and the currently installed LDT has
slots for the code and data segments that the user will use.

Am I not jumping into user space correctly?  Is there something
else that my code should do to make the transition?

On a documentation question, is __HYPERVISOR_iret documented
anywhere?  The Xen API* doesn't seem to include any details on it.
I deduced the stack arguments from looking at the code in the Linux
xen architecture and the xen-x86_64.h header.

This comment in the header, however, doesn't seem to match the
behaviour that my code seems to experience:

 * If flags contains VGCF_in_syscall:
 *   Restore RAX, RIP, RFLAGS, RSP.
 *   Discard R11, RCX, CS, SS.
 * Otherwise:
 *   Restore RAX, R11, RCX, CS:RIP, RFLAGS, SS:RSP.

I am passing flags==0 and only push the values for flags, CS:RIP,
RFLAGS, and SS:RSP.  If I push values for RAX, R11, and RCX on the
stack the kernel ends up in all sorts of weird places rather than
my intended RIP and RSP.

-- Trammell


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>