should syscall be trap or interrupt

[Octocontrabass]

if the ISR set up code looks like the follows, there is no difference between trap gate and interrupt gate...

No, an IRQ can still occur after the CPU jumps to the interrupt handler but before the CLI instruction. You must use an interrupt gate if you don't want to allow IRQs at that point.

[nullplan]

No, an IRQ can still occur after the CPU jumps to the interrupt handler but before the CLI instruction. You must use an interrupt gate if you don't want to allow IRQs at that point.

Addendum: If your context switch requires more than the CPU will provide (e.g. having to run "swapgs"), or if you don't want the potential for stack exhaustion under heavy load, you definitely must use interrupt gates only. With trap gates there is a potential that a second interrupt arrives before the first has completed the context switch, thus making the second interrupt run in an inconsistent state. Under heavy load, there is also the possibility that interrupts arrive constantly before your handler is able to CLI, thus exhausting the kernel stack at some point. Trap gates are a nice idea but they only work in some specific circumstances, and are otherwise too complicated to bother with.

[bzt]

Hi,

It is trap if the return address is after the instruction that the trap occur (eg. int 0x80)
It is faults(aka exception) if the instruction causing the faults gets re-executed.

Basically yes, but I wouldn't call the first one trap, because trap is a kind of exception too (thus overlaps with your second point), plus this behaviour also goes for interrupts (IRQs and soft-int).

<rant> It would be better if Intel engineers were not incompetent, and they should have called the IDT entries "exception gate" and "interrupt gate" or they should have classify exceptions as fault, continuable and abort (or something like that). It is very confusing that they call all exception descriptors "trap" gate, but also a kind of exception is named "trap" too, which happens to act just like the interrupt gate from the continuation point of view... It is a complete naming mess.</rant>

To sum it up:
abort - trap gate that saves unrelated IP (basically NMI and such)
fault - trap gate that saves the current IP
trap - trap gate that saves the next IP
interrupt - interrupt gate that saves the next IP

In this context your original question makes no sense because both trap exceptions and interrupts save the next IP. Otherwise I think you're getting the right idea about these things. I personally would never use a trap gate for a soft-int, only interrupt gate (Octocontrabass and nullplan are right about IRQs could be triggered).

Cheers,
bzt

[nullplan]

To sum it up:
abort - trap gate that saves unrelated IP (basically NMI and such)
fault - trap gate that saves the current IP
trap - trap gate that saves the next IP
interrupt - interrupt gate that saves the next IP

Now you're mixing up interrupt types and gate types. Trap gates are specific descriptors in the IDT. They describe an entry to an ISR, and if used, they leave the interrupt flag unmodified. Interrupt gates are specific descriptors in the IDT that describe an ISR, and if used, they clear the interrupt flag before resuming execution at the ISR.

<rant> It would be better if Intel engineers were not incompetent, and they should have called the IDT entries "exception gate" and "interrupt gate" or they should have classify exceptions as fault, continuable and abort (or something like that). It is very confusing that they call all exception descriptors "trap" gate, but also a kind of exception is named "trap" too, which happens to act just like the interrupt gate from the continuation point of view... It is a complete naming mess.</rant>

The two most complicated problems in engineering are cache invalidation, naming things, and off-by-one errors. Looks like Intel are proving number two again here.

[iansjack]

I think one of the big mistakes that was made was to conflate system calls and interrupts. (Remember - way back when - this was a thread about system calls.) They actually put that right and provided a specific system call instruction; but they made the mistake of assuming that everyone would use it.

[bzt]

Now you're mixing up interrupt types and gate types.

Not mixing up, but providing an overview matrix for them. Before the "-" is the interrupt type (on all lines), and after separator the gate type (for all lines). Sorry if this wasn't clear for you.

Remember - way back when - this was a thread about system calls.

More precisely IDT-based syscalls, and also about if the interrupted instruction is recomputed or not.

Cheers,
bzt

[sj95126]

I'll second the recommendation to use sysenter/sysexit (or syscall/sysret) instead. I converted my code to use it and it only took a few minutes. The only reason it didn't work perfectly on the first try is because the documentation doesn't draw enough attention to the fact that sysenter automatically clears the interrupt flag but you have to do an sti immediately before sysexit. (the syscall worked, but everything timer-related stopped)

[iansjack]

I'm only familiar with the 64-bit syscall/sysret instructions. syscall saves the return address in RCX, RFLAGS in R11, and then set RFLAGS according to a pre-defined mask. sysret then restores RFLAGS. Because return address and flags are saved in registers, and segment selectors are loaded from pre-defined values (rather than accessing the descriptor tables) the call is about as fast as you could reasonably expect. Much, much faster than using a software interrupt or a call gate.