QQRE: [elysium-developers] IRQ handling

[Kasper V. L. <ve...@da...>]

> > A - low-latency - solution could be:
> > * a device generates IRQ 7
> > * the running process is interrupted by interrupt 0x27 which traps to
the kernel
> > * the kernel calls the IRQ handler for IRQ 7 using a task state segment
>
> So in this case the kernel saves state?

Yes, either the kernel saves the state or the CPU does it automatically - it
depends on wether we use task state segments (the hardware way) or not.

> > * when the handler is done (this might be time bounded) it returns using
iret
>
> Erm, no. The kernel is calling (thus it's an upcall into
> userland), therefore wouldn't the process return w/ a simple ret?

If we choose to use task state segments the way to return to the previous
task (in this case normally the kernel) is via a iret instruction. I refer
to the Intel Architecture Software Developer's Manual (Vol. 3, 6-10):

"The processor transfers execution to another task ... when the current task
executes an IRET when the NT flag in the EFLAGS is set."

On the other hand if we choose not to use hardware saving of state the
process should use RET - so you're somewhat right.

Details on the Proposal
=======================
So my proposal (using task state segments) is to have a task state segment
for each IRQ (at least 1 - 15, we need IRQ 0 for the scheduler). Whenever
the IRQ fires the kernel will switch to the IRQ handler task. If an IRQ
handler is running it can only be interrupted by another IRQ handler with
higher priority (that's the way the PIC works), and since the kernel doesn't
acknowledge the IRQ (by sending the EOI) before the IRQ handler is done the
IRQ handler will never be interrupted by itself. Fx if an IRQ handler for
IRQ 7 is running it will never be interrupted by another IRQ 7 handler.

One possible scenario is the following:
* process A is running
* process A is interrupted by IRQ 7 handler
* IRQ 7 handler is interrupted by IRQ 1 handler (which has higher priority)
* IRQ 1 handler terminates with an IRET
* IRQ 7 handler is resumed
* IRQ 7 handler terminates with an IRET
* process A is resumed

Is it a problem that a handler for an IRQ never can be interrupted by
another request for the same IRQ?

/Kasper