On Mon, Jul 14, 2014 at 3:23 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 07/14/2014 02:35 PM, Andy Lutomirski wrote: >> Presumably the problem is here: >> >> ENTRY(xen_iret) >> pushq $0 >> 1: jmp hypercall_iret >> ENDPATCH(xen_iret) >> >> This seems rather unlikely to work on the espfix stack. >> >> Maybe espfix64 should be disabled when running on Xen and Xen should >> implement its own espfix64 in the hypervisor. > > Perhaps the first question is: is espfix even necessary on Xen? How > does the Xen PV IRET handle returning to a 16-bit stack segment? >
Test case here: https://gitorious.org/linux-test-utils/linux-clock-tests/source/dbfe196a0f6efedc119deb1cdbb0139dbdf609ee: It's sigreturn_32 and sigreturn_64. Summary: (sigreturn_64 always fails unless my SS patch is applied. results below for sigreturn_64 assume the patch is applied. This is on KVM (-cpu host) on Sandy Bridge.) On Xen with espfix, both OOPS intermittently. On espfix-less kernels (Xen and non-Xen), 16-bit CS w/ 16-bit SS always fails. Native (32-bit or 64-bit, according to the binary) CS with 16-bit SS fails for sigreturn_32, but passes for sigreturn_64. I find this somewhat odd. Native ss always passes. So I think that Xen makes no difference here, aside from the bug. That being said, I don't know whether Linux can do espfix64 at all when Xen is running -- for all I know, the IRET hypercall switches stacks to a Xen stack. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
