>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
|
Home