6

In older versions of linux architecture, system calls would always generate an interrupt during their execution. They would be executed by setting the system call number into %eax and parameters into %ebx, %ecx and so on, followed by issuing the specific interrupt int 0x80. Thus, system calls could be said to be a common cause of software interrupts on a system.

However, on modern architectures of x86_64 there is a specific system call instruction "syscall", which bypasses the need to use interrupt 0x80, and thus, the interrupt descriptor table at all. While I believe the previous method of generating an interrupt for syscall is still supported, the syscall instruction seems to be the way it's done in practice.

Thus, my question is: Is it no longer correct to say that system calls generate interrupts? Would a system call still increment the number seen in the "interrupts" column output of vmstat, for example?

arrwags
  • 63
  • 4

1 Answers1

5

Yes, modern C code for Linux x86_64 uses the syscall instruction, see for example glibc sysdeps/unix/sysv/linux/x86_64/syscall.S. No, this does not mean system call interrupts go away, due to compatibility.

https://www.kernel.org/doc/Documentation/x86/entry_64.txt

The x86 architecture has quite a few different ways to jump into kernel code. Most of these entry points are registered in arch/x86/kernel/traps.c and implemented in arch/x86/entry/entry_64.S for 64-bit, arch/x86/entry/entry_32.S for 32-bit and finally arch/x86/entry/entry_64_compat.S which implements the 32-bit compatibility syscall entry points and thus provides for 32-bit processes the ability to execute syscalls when running on 64-bit kernels.

The IDT vector assignments are listed in arch/x86/include/asm/irq_vectors.h.

Some of these entries are:

  • system_call: syscall instruction from 64-bit code.

  • entry_INT80_compat: int 0x80 from 32-bit or 64-bit code; compat syscall either way.

  • entry_INT80_compat, ia32_sysenter: syscall and sysenter from 32-bit code

And for read only syscalls (gettimeofday) there is vDSO which does not enter kernel mode at all.

system calls can be profiled in a few ways, such as ftrace or eBPF. In addition to being obsolete in 64 bit mode, interrupts happen for reasons other than system calls.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • 1
    Thank you for this great explanation. To make sure I fully understand, syscalls will still generate interrupts due to compatibility with entry points such as you described for "entry_INT80_compat" which may be used by either 32-bit or 64-bit code and will still incur a traditional interrupt. However, if syscall instruction is used from 64-bit code, then a traditional software interrupt would not occur. Do I understand correctly? – arrwags Oct 30 '17 at 05:07
  • 1
    Causation is the other way around: 32 bit C code uses interrupts to call syscalls. Correct, interrupts are not used for the 64 bit mode syscall instruction, compare the implementation in your favorite C library. All of this only discusses x86 architecture, by the way. – John Mahowald Oct 30 '17 at 14:32