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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
