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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>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