What's the difference between a 'fast' (instruction) syscall and interrupt-driven system call?

Question

From my understanding, the syscall/sysenter instructions and their companions were introduced in recent architectures to serve as a shorter path into the kernel. But I don't understand how it achieves that.

This answer says as much, with the justification that they have to do less operations and are register-based.

On the other hand, when you trigger a soft interrupt with the intent of a system call ...

the CPU doesn’t know that that’s what you’re doing. It needs to read the target CS and EIP values from the interrupt descriptor table. The value of CS specifies what the target privilege level is; once the CPU figures that out, it needs to determine what the target state is, which involves more reading from memory.

But isn't that exactly what the SYSCALL instruction might do? (And does, in the case of the x86-64 instruction set as mentioned on page 1907 of TFM?) I suppose the exact mechanism is technically ABI dependent. But won't the CPU have to check the instruction against some LUT that has to be in memory?

I might be a little fuzzy on who exactly (amongst compiler, architecture, and OS vendor) is enforcing what, so please be gentle.

Answer 1

But isn't that exactly what the SYSCALL instruction might do?

No, syscall reads MSRs (model specific registers) for the new CS:RIP, and for a mask for RFLAGS, not memory pointed-to by IDTR.

And it doesn't change RSP or do any loads or stores, so it doesn't have to read the TSS (for a new SS:RSP) or do any page-table checks (for virtual addresses load or store) while it's in the middle of changing privilege level.

It saves the old RIP and RFLAGS in RCX and R11, respectively, to also avoid having to store anything to memory.

This keeps the instruction minimal so the tricky part (changing privilege level) can be finished ASAP, getting the CPU into kernel mode (ring 0). Then out-of-order exec can handle swapgs and the kernel code that loads a new stack pointer (typically from gs:somewhere; this is the intended mechanism for the kernel to get itself a kernel stack pointer), after saving the user-space RSP somewhere (probably also relative to the gs base.)

https://www.felixcloutier.com/x86/syscall