Re: In kernel PIC support: kernel patch

On Thu, 2007-06-21 at 22:57 +0800, Dong, Eddie wrote:

Gregory Haskins wrote:

quoted

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



-------------------------------------------------------------------------
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/