Re: In kernel PIC support: kernel patch

Gregory Haskins
2007-06-21T15:10:04Z

On Thu, 2007-06-21 at 22:57 +0800, Dong, Eddie wrote:
> Gregory Haskins wrote:
>
> > So assuming this newly enlightened position is true, I think this
> > means we have a choice:
> >
> > 1) Drop support for mixed "level-1" mode and move the PIC to the
> > kernel now as Eddie is doing
> >
> > 2) Keep the level-1/2 distinction, and add support for making sure
> > that once a vector is acked in the PIC, it truely gets put into
> > service immediately.
> >
> > I can think of a really simple interface for (2). All we
> > really need to
> > do is
> >
> > a) go back to synchronous injection (as previously suggested)
>
> For level-2 support, that means no PIC/APIC in user space, it is the
> device want to assert/dessert an irq line request. There is no notion
> of injecting IRQ. That is why I added new APIs.
> Even with level-1 in consideration, we still need these new APIs to
> support level-2. A device such as kerboard could frequently assert
> and dessert the irq line. A single ker strobe will see 5-10 dessert
> request from device model and 1 assert request.
>
> So new APIs are a must IMO.

Fully agree, but I already added them as well ;)

1) KVM_ISA_INTERRUPT: In level-1 mode, this API allows the userspace
pic to dispatch a vector to the kernel. In level-2 mode, this allows
any userspace app to tickle an isa based irq line (which feeds into the
inputs of the PIC and IOAPIC. In other words, a level-2 based userspace
would substitute KVM_ISA_INTERRUPT for pic_set_irq().

2) KVM_APIC_MESSAGE allows any entity (presumably an IOAPIC in
userspace, though there is no restriction here) to send APIC messages.
This will probably only be used in level-1 mode, but its there for both
modes nonetheless.

-Greg