edmundo@rano.demon.co.uk writes:
Jochen Liedtke asked, and I think it's a crucial question:
are the interrupts constantly disabled from raising the interrupt until executing that code?
Looking at the code, I think the answer is yes. (There is, however, quite a lot of code between the interrupt happening and the non-specific EOI being issued, and there are lots of macros and conditional compilations, so I might be wrong.
Unfortunately, you are wrong: Fiasco likes to enable interrupts (because it is a real-time kernel), and there is no guaranty at all that irqs will remain disabled until the EOI is issued (even if the irq thread enters the kernel with interrupts disabled).
Is it possible to inspect the state of the interrupt-disable flag using remote gdb?)
Yes, with "info registers" (or "i r" for short). But when you're in the debugger, it will be too late.
In which case I no longer understand what Jean Wolter wrote about priority assignment to interrupt threads. If interrupts are constantly disabled from raising the interrupt until the non-specific EOI, how can the priorities matter? If the PIC can "deliver" an interrupt with higher priority while interrupts are disabled,
It can't.
and if the non-specific EOI then acknowledges the highest-priority interrupt that was delivered,
It doesn't, in the sense of "deliver" you defined above.
as opposed to the hightest-priority interrupt that is being serviced, then we are always in trouble if we issue a non-specific EOI with interupts disabled. In this case, should we reenable interrupts before doing the EOI?
But I can't think why the PIC should have been designed this way.
It isn't. Unspecific EOI acknowledges the latest irq that has been accepted by the CPU, and if the CPU is in "cli" mode, it will not accept an irq no matter what its hardware priority in the PIC is.
So, given that the CPU operates in "cli" mode, hardware priorities don't matter.
But it doesn't operate in "cli" mode at all times. And even if it would, there are problems with the irq threads' software priorities: Unlike L4/x86, Fiasco doesn't deliver an irq-IPC message to an interrupt thread if there is a different thread with a higher priority; instead, the irq ``sender'' is blocked and queued in the irq thread's sender queue. This can lead to a thread different from the irq thread being scheduled and, as a consequence, to interrupts being enabled in the CPU ("sti" mode).
[...] To reconcile this, I am lead to conclude that my inspection of the code is mistaken, interrupts are not disabled constantly from raising the interrupt until issuing the EOI, and this is deliberately so,
This is correct.
but somehow we are ending up in the wrong interrupt thread after a higher-priority interrupts interrupts a lower-priority one.
Yep. Maybe some event or IPC caused an lower-priority irq thread to be scheduled before a higher-priority irq thread could acknowledge its irq.
I'm really out of my depth here. Can anyone recommend a good book, or other source of information, about x86 and PIC programming? (I don't need an introduction to assembler programming, as I did a lot of 6502 and 8080 as a child, but I don't know much about x86 specifics or about interrupt details.)
I don't know of any good book describing PIC programming. The best reference I could find was a specification of the ``legacy interrupt controller'' for the PowerPC CHRP platform (which probably emulates the PIC's interface for old x86-PC hardware). But this is only a specification and not a programming manual. Among other places, it's available in Chapter 4 of URL: ftp://ftp.austin.ibm.com/pub/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf.
You might also want to try doing a websearch on "programmable interrupt controller programming" or somesuch; I just did a quick search, and URL:http://www.geocities.com/SiliconValley/Bay/8302/interupt.htm seems to be a nice intro, but it doesn't discuss the special fully nested mode Fiasco uses. A search on "special fully nested mode" brought up a description of a PCI bridge containing PIC functionality at URL:http://www.intel.com/design/intarch/techinfo/430tx/ticTOC.htm.
Michael
l4-hackers@os.inf.tu-dresden.de