Re: In kernel PIC support: kernel patch

Dong, Eddie
2007-06-21T15:13:55Z

We are in same page now :-)

Gregory Haskins wrote:
> 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