During a context switch from a usermode process (which has a TLS
segment set up, and %gs pointing to it) to a kernel process (which has
no TLS and a null %gs selector), there's a period when %gs contains a
stale selector value after updating the GDT.  This causes Xen to
hiccup because on returning from the GDT update hypercall as it tries
to reload %gs and suffers another fault.

This patch words around this by zeroing %gs during the context switch
so that it doesn't cause problems, but the real fix is to change Xen
to avoid touching %gs when it doesn't need to.

Signed-off-by: Jeremy Fitzhardinge <redacted>

===================================================================

--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c

@@ -719,6 +719,14 @@ struct task_struct fastcall * __switch_t
 	savesegment(gs, prev->gs);
 
 	/*
+	 * Temporary hack: zero gs now that we've saved it so that Xen
+	 * doesn't try to reload the old value after changing the GDT
+	 * during the context switch.  This can go away once Xen has
+	 * been taught to only reload %gs when it absolutely must.
+	 */
+	loadsegment(gs, 0);
+
+	/*
 	 * Load the per-thread Thread-Local Storage descriptor.
 	 */
 	load_TLS(next, cpu);

--