To be compatible with Windows?
Unsurprisingly, Windows does it for the same reason.
Or maybe (I'm guessing) because there is some special CPU support in 64-bit mode for GS register but not for FS - SWAPGS instruction: http://www.felixcloutier.com/x86/SWAPGS.html
Maybe something can be done more efficiently with SWAPGS than without it.
You got it! The thing that can be done more efficiently with SWAPGS is system calls.
The SYSCALL instruction
is used to perform a fast system call. It transfers control to a specific location, elevates the privilege level to ring 0 (i.e. "kernel mode"), saves the CPU flags into one specific register (r11), and disables interrupts. It doesn't change any other registers, including the stack pointer. This is much, much faster than the way things used to be done (e.g. software interrupts), which involved saving registers to a stack at a known location, switching stacks, and so on.
So when you enter the kernel, almost all of the CPU registers are set to what they were in user space. The first thing the kernel has to do is save that user state. But where should it save the state to?
Note that it can't compute a location, because any computation would use registers. Using static space would work on a single core, but not on a multicore machine.
The answer is to use SWAPGS. In kernel space, GS points to the kernel's per-cpu information, and in user space, it points to user-space per-thread information. SWAPGS swaps gs with a MSR, which can be set per-CPU at boot time.
Here's the relevant code from Homebrew OS:
// Calling convention on HBOS is that %rax contains
// the system call number when you enter a system call and
// contains errno when you exit. This is a fast path to make sure
// that the number makes sense. Note that this doesn't change
// the values in any registers or use any stack.
// Swap the user-space thread-local storage with the kernel's
// per-cpu state for this CPU.
// %gs:0 now points to the kernel's per-CPU state.
// We can now freely use this without interfering with
// anything that other CPUs are doing.
// Swap stacks...
// Now we are on a known good stack, so we
// have a place to save a register so we can do
// some computation.
// %rax now points to the kernel's thread control block.
// Remember that we entered the kernel via a syscall as
// opposed to, say, an interrupt. Eventually we will probably
// want to return control to the thread, so we have to make
// sure we exit in the opposite way that we entered.
// Now that we have the TCB, save registers into it...
// We temporarily stored the user-space stack
// pointer in CPUSTATE_SAVED_STACK...
// ...and we temporarily stored %rax on the stack.
// All registers are now saved, and we're on a known
// good kernel-space stack. We can now call into C
// code and everything will work.
The sysret code does essentially the same thing only in reverse. The kernel changes the saved copy of the GS when it does a context switch, so when the system call exit code (sysret) does a final SWAPGS, the correct thread-local storage pointer is swapped back in.