Re: In kernel PIC support: kernel patch

Gregory Haskins
2007-06-21T15:42:13Z

On Thu, 2007-06-21 at 15:17 +0000, Gregory Haskins wrote:
> On Thu, 2007-06-21 at 22:28 +0800, Dong, Eddie wrote:
> >
> > > I suppose, but it somewhat defeats the purpose IMO. Every pin in the
> > > 8259 that gets tickled implicitly means an IOAPIC pin was tickled
> > > also. Do we really want to go to userspace for that? Essentially
> >
> > User space can handle this, go to IOAPIC first and then decide to go to
> > in kernel PIC or not. Here the assumption is that an irq line is either
> > serviced
> > by PIC or IOAPIC, it will never be serviced by both.
> >
> > So no back to user space.
>

Thinking about it some more, I see some conditions where this
optimization doesn't work (and was one of the reasons driving my
redesign of the subsystem). For instance, when linux routes the PIT as
an NMI and an IOAPIC based event. In this case, the PIT raises an
interrupt which tickles an isa interrupt line that should be routed to
both the PIC and the IOAPIC #IRQ0. Both devices should have IRQ0
unmasked. The former will get routed to the APIC via tickling the LINT0
line. The latter will get routed as an APIC-MSG based on the
programming of the IOAPICs IRQ0 line.

I believe this is a scenario which is mis-emulated today at least
partially due to the assumption that only one device is in use at a
time.

All is not lost, however. This just helps drive the decision to move
the IOAPIC with the PIC ;)

-Greg