Re: QQRE: [elysium-developers] IRQ handling

[Adam L. <ag...@li...>]

On Tue, Feb 08, 2000 at 02:49:36PM +0100, Kasper Verdich Lund wrote:
> > > 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.
>

Ah, ok. I've got the Insight Cd somewhere (I'd better read it sometime)!

> 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?

I don't think so. The IRQ will be dropped if that come too fast wont they? That must happen in all kernels so someone else must have solved the problem, if there is a problem to solve. I think we might have a problem with somethings like net cards:

* Packet arrives
* IRQ 9 handler called
* Packet arrives
* IRQ 9 handler ends

Now I think the second IRQ would be dropped by the PIC, not qued. so the second packet wouldn't be handled. But cards might have a way around this (e.g. a register to poll, at the end of the handler.)

AGL