[src/trunk]: src/sys/arch/amd64/amd64 It appears that Xen remaps the userland...

[maxv <maxv%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/7839eaa8a4c4
branches:  trunk
changeset: 827449:7839eaa8a4c4
user:      maxv <maxv%NetBSD.org@localhost>
date:      Sat Oct 28 20:06:31 2017 +0000

description:
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.

diffstat:

 sys/arch/amd64/amd64/locore.S |  6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diffs (20 lines):

diff -r 5281da6ace71 -r 7839eaa8a4c4 sys/arch/amd64/amd64/locore.S
--- a/sys/arch/amd64/amd64/locore.S     Sat Oct 28 19:28:11 2017 +0000
+++ b/sys/arch/amd64/amd64/locore.S     Sat Oct 28 20:06:31 2017 +0000
@@ -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 @@
        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;)