WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: 32-on-64 sysenter for pvops

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: 32-on-64 sysenter for pvops
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 04 Mar 2008 08:38:09 +0000
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Delivery-date: Tue, 04 Mar 2008 00:38:04 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47CCA07A.50902@xxxxxxxx>
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>
References: <47CCA07A.50902@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>Anyway, a couple of questions.  It seems that the stack frame that Xen's 
>sysenter generates is not exactly the same as the one the kernel 
>expects, so the direct access to the threadinfo structure doesn't work 
>properly.  What's the difference in the frames?

The frame is a normal interrupt frame (but not completely/properly filled
in - the implication of course is that the stack has been switched, other
than native sysenter would do), which is why the code in our kernels just
is a special preamble to system_call:

...
ENDPROC(ia32_sysenter_target)

        # pv sysenter call handler stub
ENTRY(ia32pv_sysenter_target)
        RING0_INT_FRAME
        movl $__USER_DS,16(%esp)
        movl %ebp,12(%esp)
        movl $__USER_CS,4(%esp)
        addl $4,%esp
        CFI_ADJUST_CFA_OFFSET -4
        /* +5*4 is SS:ESP,EFLAGS,CS:EIP. +8 is esp0 setting. */
        pushl (TI_sysenter_return-THREAD_SIZE+8+4*4)(%esp)
        CFI_ADJUST_CFA_OFFSET 4
/*
 * Load the potential sixth argument from user stack.
 * Careful about security.
 */
        cmpl $__PAGE_OFFSET-3,%ebp
        jae syscall_fault
1:      movl (%ebp),%ebp
.section __ex_table,"a"
        .align 4
        .long 1b,syscall_fault
.previous
        /* fall through */
        CFI_ENDPROC
ENDPROC(ia32pv_sysenter_target)

        # system call handler stub
ENTRY(system_call)
...

>I guess the other reason for the separate PV Xen sysenter entrypoint is 
>to deal with sysexit not working.  I addressed this by implementing a 
>sysexit pvop using iret, though I think I could just set the TIF_IRET 
>flag in threadinfo.

Either should work, but as pointed out above letting it just fall through
to system_call seems even easier.

>Anyway, could you look at these changes and see if anything problematic 
>leaps out.

This description

>The sysenter path tries to enable interrupts immediately.  Unfortunately
>this doesn't work in a paravirt environment, because not enough kernel
>state has been set up at that point (namely, pointing %fs to the kernel
>percpu data segment).  To fix this, defer ENABLE_INTERRUPTS until after
>the kernel state has been set up.

seems bogus: The sysenter handler in our kernels gets called with
interrupts enabled, which is as safe as int $80 going through a trap gate
(i.e. the rest of the kernel needs to be prepared to deal with interrupts
being enabled here anyway).

Jan


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

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