Does instruction "iret" automatically restore interrupt?

[torshie]

Should I issue the instruction "sti" before "iret" in an interrupt handler?

[Brendan]

Hi,

Should I issue the instruction "sti" before "iret" in an interrupt handler?

No, and you shouldn't do CLI at the start of an interrupt handler either.

The CPU pushes EFLAGS on the stack when it starts the interrupt handler and can also (if it's an interrupt gate) disable interrupts for you (mostly to avoid race conditions - e.g. if an IRQ occurs after the interrupt handler is started but before you get a chance to do CLI); and when you do IRET the CPU pops the original EFLAGS off of the stack, which includes the original state of the interrupt enable/disable flag.

In some cases, doing a STI near the end of an interrupt handler can stuff things up (e.g. a critical section that's meant to run with interrupts disabled, that uses a software interrupt, where the software interrupt stuffs things up by enabling interrupts). In the majority of cases, doing CLI at the start of an interrupt handler or doing STI at the end of an interrupt handler is only a waste of time (and doesn't cause any serious problem).

Basically, usually you should never use STI or CLI (or need to use STI or CLI) anywhere in an interrupt handler, but there is one special case.

For an interrupt that uses an interrupt gate (where interrupts are automatically disabled by the CPU), it can make sense to do something important (e.g. acquire some sort of re-entrancy lock, or switch to a different stack, or send an IPI) and then enable interrupts; and it can also make sense to disable interrupts near the end of the interrupt handler while you do something important (e.g. free a re-entrancy lock, or switch back to the original stack, or send an IPI) before doing the IRET.


Cheers,

Brendan

[torshie]

Thank you for your detailed reply.

[bewing]

In some cases, doing a STI near the end of an interrupt handler can stuff things up ....

On the other hand, doing that can also keep the CPU in CPL 0, and avoid two unnecessary priv level switches for back-to-back interrupts ... if done carefully (especially if limited to hardware IRQs only).

[hailstorm]

I like to add that it (in reply to Brendan) depends on whether the interrupt handler is accessed through a trap or interrupt gate.
Only the latter will clear the IF flag, while the other one leaves the IF flag as is.

[Brendan]

Hi,

In some cases, doing a STI near the end of an interrupt handler can stuff things up ....

On the other hand, doing that can also keep the CPU in CPL 0, and avoid two unnecessary priv level switches for back-to-back interrupts ... if done carefully (especially if limited to hardware IRQs only).

I'd consider that a variation of the "one special case" I mentioned - e.g. start with interrupts disabled, do anything that's important, then enable interrupts for the remainder of the IRQ handler (to allow IRQ nesting)...

[EDIT] Mainly the idea I wanted to convey is that for interrupt handlers, if necessary, you should only use "STI then CLI" (rather than the opposite order, "CLI then STI", which might seem more natural to beginners).[//EDIT]


Cheers,

Brendan