[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: 32-on-64 sysenter for pvops
Jan Beulich wrote: 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: Yes, I copied that code more or less unchanged. ... 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,%espI 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. It means you need to duplicate more code. My variant just has the Xen-specific stack setup on entry, but then it can just fall back to the normal path. 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). It's a principled fix. It's true that there's only a visible problem when making the Xen sysenter address point to the normal sysenter target - which doesn't work because of the different calling convention. But if it did work (ie, Xen - or another hypervisor - produced the same frame as the normal sysenter instruction), then ENABLE_INTERRUPTS would fail because it's being called before the kernel's percpu segment has been set up. So given that ENABLE_INTERRUPTS needs to happen later, I set up xen_sysenter_target to enter with events masked, so that it's as similar to the hardware instruction as possible, and interrupts enabled are in the same place in both cases. J _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |