Random Ideas for the Design of the APIC INTerrupt System


BTW, I've been thinking about the apic masking issues, and I think there is a safer alternative...

Given the following assumptions: - masking an io apic's "enable" bit causes it to loose interrupts in edge trigger mode, rather than save one like the 8259's do. - we need to mask "level" interrupts or we get recursion on EOI if we are deferring the interrupt.

My initial thoughts are that we need a different strategy for each type, and both would be reasonably different to the 8259 case (they are different animals). I think Bruce once mentioned some stats on the deferred masking over a long uptime on a machine... It was something in the order of a small fraction of a percent of interrupts (on an 8259 system) were actually blocked by the pic masking (and hence the lazy masking strategy).

Perhaps we can go further.. For edge trigger interrupts, how about we NEVER mask the hardware interrupt line, and simply wear the small number of extra interrupts that were "do nothings" because the bit in ipending was already set.

Also, we should keep in mind that we will need to deal with systems that have some interrupts only visible to the 8259's and are not connected to the APIC (eg: one of Dell's current range apparently). On these systems, we have 16 "mask" bits in imen, plus at least 16 more APIC "mask" bits, plus the 4 software interrupt bits. That's more than 32 for those who are counting.... I think it's time to have the "mask" in terms of "HWI_TTY", "HWI_BIO" etc. Each interrupt (of a maximum of 224) is tagged as "tty", "bio", etc and checks the "group" mask to see if this interrupt is masked by another or not. spltty() changes from "cpl |= tty_imask" to "cpl |= HWI_TTY" and so on.

Macros like INTREN() would be thrown into chaos by this, as they'd need to know whether the IRQ was being handled on an 8259 input, or on one of the IO apics.. Oh, what fun.. :-)

Cheers,
-Peter