Module Name: src
Committed By: maxv
Date: Sat Oct 28 20:06:31 UTC 2017
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
It appears that Xen remaps the userland %cs to 0xE033. So add it to the
checklist. Otherwise we're going through Luexit32: %fs gets reloaded,
which sets the FS.base to NULL, which will cause the thread to page-fault
next time it accesses its TLS (as seen in PR/52662).
This fix is not very clean, and it would be nice to understand why Xen
remaps %cs. But I'm committing it now anyway, so that people can test.
To generate a diff of this commit:
cvs rdiff -u -r1.138 -r1.139 src/sys/arch/amd64/amd64/locore.S
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/arch/amd64/amd64/locore.S
diff -u src/sys/arch/amd64/amd64/locore.S:1.138 src/sys/arch/amd64/amd64/locore.S:1.139
--- src/sys/arch/amd64/amd64/locore.S:1.138 Sat Oct 21 08:08:26 2017
+++ src/sys/arch/amd64/amd64/locore.S Sat Oct 28 20:06:31 2017
@@ -1,4 +1,4 @@
-/* $NetBSD: locore.S,v 1.138 2017/10/21 08:08:26 maxv Exp $ */
+/* $NetBSD: locore.S,v 1.139 2017/10/28 20:06:31 maxv Exp $ */
/*
* Copyright-o-rama!
@@ -1483,6 +1483,10 @@ ENTRY(intrfastexit)
je .Luexit64
cmpw $GSEL(GUCODE_SEL, SEL_UPL),TF_CS(%rsp)
je .Luexit64
+#ifdef XEN
+ cmpw $0xe033,TF_CS(%rsp)
+ je .Luexit64
+#endif
.Luexit32:
NOT_XEN(cli;)
