Re: 32-on-64 sysenter for pvops

["Jan Beulich" <jbeulich@novell.com>]

>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