system calls

[Rob]

In the various threads I've seen quite a few people talk of system calls in their respective kernels being implemented with (software) interrupts, like linux / DOS.

I was wondering why people are using that method instead of the newer options like syscall / sysenter (I know one is only for 64-bit)? Are you targetting old (older?) hardware? Since syscall has been here since Pentium 2 / 3.

Or was it not around when you started development?

Do you plan to add support for it? Like, detect sysenter through CPUID and if it exists use that and if it doesn't fall back to ints?

[McZ]

I have just started to read about the interface between C lib, kernel and userspace applications for functions like fopen etc.

And I would like to know how the syscall/sysenter works, wich one is only 64bit?

[Pype.Clicker]

since AMD guys are the ones that introduced x86-64 the AMD system call (think it is sysenter but i might be wrong) is the only one that is available in 64-bit mode. Intel followed that _too_ in EM64T, at the expense of their own extension.

In other words, on AMD chips, you use the same "opcode" to quickly trap to kernel regardless of whether you're in protected or long mode while on Intel chips you're using the Intel extension in pmode and AMD extension in lmode

Isn't free market the beautiest thing ever

@candy: bash me if i said something stupid on this one, will you.

[Rob]

So any thoughts on this for Clicker, Pype?

sysenter (& sysexit) is 32-bit, syscall (& sysret) 64-bit. Check the AMD/Intel manuals.

You can also use sysenter in 64-bit it seems (but not syscall in 32-bit). The opcodes *are* different Pype!

sysenter: 0x0F 0x34
syscall: 0x0F 0x05

(checked both the Intel & AMD manuals)

[Solar]

I was wondering why people are using that method instead of the newer options like syscall / sysenter (I know one is only for 64-bit)? Are you targetting old (older?) hardware? Since syscall has been here since Pentium 2 / 3.

Or was it not around when you started development?

I remember I chose i586 as baseline for Pro-POS back then for some reason or another that had to do with something like that, but as that project got discontinued long before reaching the point of supporting system calls...

In PDCLib, I quite frankly don't care, as long as the API can be tweaked to fit the PDCLib glue functions.

[Pype.Clicker]

The opcodes *are* different Pype!

Sure. Never meant they were the same ...

Syscall cannot be invoked in 32bit

they can ... at least on an AMD 32-bit chip. Here's the initial document from AMD where they introduced syscall/sysret together with 3DNow! technology (in '98).

Now, probably the later chips from AMD _also_ support sysenter/sysleave ... couldn't tell for sure.

Code: Select all

vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse

Code: Select all

vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 246
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow

Code: Select all

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.00GHz
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr

PS: machines above are not open for OS testing

So any thoughts on this for Clicker, Pype?

I have an AMD test machine that should support SYSCALL, but my main test machine (DinoLaptop) still runs a good old pentium, without any accelerated system calls, so i had to work with INT nn as a start. The "userlevel support" module could be forked with a SYSENTER-supporting and a SYSCALL-supporting variant... the main problem would remain userlevel software that needs to be upgraded. Yet "INT nn" is two bytes just like SYSxxx, so the "INT nn" handler could be rewriting the calling instruction as "SYSxxx" before it branches to the ISR, providing Just-in-Time processor retargetting

[Rob]

There seems to be a difference on AMD & Intel:

AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and system Instructions Rev 3.11 says (page 341 [or 373 in the PDF]):

Transfers control to a fixed entry point in an operating system. It is designed for use
by system and application software implementing a flat-segment memory model. This
instruction is valid only in legacy mode.

So it seems sysenter is only valid in 32-bit (legacy) mode and syscall can be used both in 32-bit and 64-bit.

IA-32 Intel? Architecture Software Developer's Manual Volume 2B: Instruction Set Reference, N-Z says (page 320 [324 in the PDF]): valid in both modes

Or to sum it up:

SYSCALL/SYSRET INTEL: 64-bit = valid, 32-bit = invalid
SYSCALL/SYSRET AMD: 64-bit = valid, 32-bit = valid

SYSENTER/SYSEXIT INTEL: 64-bit = valid; 32-bit = valid
SYSENTER/SYSEXIT AMD: 64-bit = invalid; 32-bit = valid

Of course this says nothing about earlier [32-bit] processors

[Brendan]

Hi,

I was wondering why people are using that method instead of the newer options like syscall / sysenter (I know one is only for 64-bit)? Are you targetting old (older?) hardware? Since syscall has been here since Pentium 2 / 3.

Or was it not around when you started development?

First, a summary:

• Software Interrupts: Available on all CPUs. Smallest instruction (2 bytes).
  Call Gates: Available on all CPUs. A little faster than software interrupts. Larger instruction (7 bytes). A little messier to implement.
  Exceptions: Available on all CPUs. Typically slower and messier depending on which exception you use. For example, you could use the "UD2" instruction and detect it within the undefined opcode handler, but then there's an additional "was it a system call" test. For "busier" exception handlers it can be worse.
  SYSENTER/SYSEXIT: Available on Intel Pentium II and later Intel CPUs (including in long mode). Also supported by recent AMD CPUs (but not in long mode). Fast and messy because GDT entries need to be in order, return information (EIP, ESP) is not saved during SYSENTER, segment limits and base addresses for CS and SS are trashed, and interrupts are disabled on SYSENTER but not restored on SYSEXIT.
  SYSCALL/SYSRET: Available on AMD K6 and later AMD CPUs. Supported by Intel chips for 64 bit code only (i.e. 16 bit or 32 bit "compatability" code running on a 64 bit Intel CPU in long mode can not use SYSCALL). Fast and messy because GDT entries need to be in order, return EIP is saved in ECX (or RCX), EFLAGS is changed (different actions for 64 bit code and 16/32 bit code), ESP not changed on call or return, and segment limits and base addresses for CS and SS are trashed.

For 64 bit code the SYSCALL/SYSRET is an obvious choice, as it's supported on all CPUs that are capable of running 64 bit code.

For 32 bit or 16 bit code (including 32 bit or 16 bit code running in "compatibility mode" in long mode on a 64 bit CPU), both SYSENTER/SYSEXIT and SYSCALL/SYSRET may or may not be supported depending on the CPU manufacturer. This makes it difficult to use either of them. Because of this, every "application" would need to detect which one to use (if any) or a seperate CPL=3 layer would be needed (e.g. a DLL or shared library that does the actual system call).

Do you plan to add support for it? Like, detect sysenter through CPUID and if it exists use that and if it doesn't fall back to ints?

I'll support SYSCALL/SYSRET (and nothing else) for 64 bit code.

For 32 bit code (including 32 bit code running in "compatibility mode" in long mode) I intend to support software interrupts, call gates, SYSENTER/SYSEXIT and SYSCALL/SYSRET. If user-level code uses SYSENTER and/or SYSCALL when the CPU doesn't support it, I'll emulate it within the undefined opcode handler. This allows the person who writes the user-level code to choose which to use (or if it's worth detecting what's supported).

I guess I should also mention that I'm supporting 80486 and later CPUs (partly because I'm hoping the OS will be used on embedded systems one day - Intel still sells new 80486's for this).

Cheers,

Brendan

[Rob]

Thanks for that Brendan. It seems your story and my latest modification to the post above yours seem to concur. Sometimes it *is* a messy world out there

p.s. Brendan: I can't seem to be able to see your site. Is it down?