Re: In kernel PIC support: kernel patch

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Gregory Haskins wrote:
>> n paravirt device drivers will want to inject IRQs via the ioapic 
>> (when the guest is not paravirt_ops enabled, like older Linux and 
>> Windows). 
>>     
>
> Note that its probably not a requirement to do so.  The IOAPIC
> essentially provides a standard mechanism to map input "irq pins" to
> APIC messages.  A pv driver could conceivably call kvm_apicbus_send()
> directly if I knew its vector instead of calling ioapic_setpin() and it
> would achieve the same goal.
>
> What is nice about using an IOAPIC is that the irq routing can be done
> for you automatically by any ACPI compliant OS.  The device just has to
> say "raise my output pin" and the IOAPIC translates that into a vector.
> If you forgo the IOAPIC in favor of direct APIC messages, you have to
> solve the problem of irq-routing a different way.  
>
>   

Very good point.  There's a slight issue that Windows with the ACPI HAL 
is dog slow when virtulalized, but maybe we can find another HAL that 
supports ACPI but doesn't use the APIC.

> Note that there is another standard that would allow us to use built-in
> routing without ACPI/IOAPIC: MSI.  I know the battle over
> virtual-bus-rendering is still raging w.r.t. to PCI or not-PCI.  But I
> will point out that if we do use PCI, setting the PV devices up as MSI
> capable in the config space potentially eliminates the need to also wire
> them to an IOAPIC.  They will get their vector data from the MSI setup
> and can then send APIC messages directly.  (I think there is some
> confusion about how we can do MSI later in this thread...I will reply to
> those mails separately)
>   

MSI is also a good solution; but do all semi-modern guest OSes support it?

>   
>> It's probably okay to implement the device side of a block 
>> device in qemu, but more difficult for networking. If we have device 
>> implementations in the kernel then we'll need an ioapic in the kernel.
>>     
>
>   
>> Also, if we end up sharing interrupts between the kernel and userspace, 
>> we'll need the kernel to perform the OR between the level specified by 
>> the kernel devices and the level specified by userspace.
>>     
>
> I not sure I fully understand what you are getting at here.  It sounds
> like you are talking about splitting a single IOAPIC into both a user
> and kernel space device?  

No, a single ioapic in the kernel, with one interrupt line that is 
shared between a kernel-provided device and a userspace-provided 
device.  The kernel would need to provide the OR function that sharing 
implies.


> If we do end up needing the IOAPIC in the
> kernel and userspace, I would suggest using two IOAPICs (we just need to
> update the ACPI tables to say there are two) so that they can operate
> independently.  This should be supportable from a virtual system
> infrastructure standpoint, and is much cleaner IMHO.  If you were
> talking about a different scenario. please clarify

I was talking about a different scenario, but your solution is cleaner 
(though it involves more hand-dirtying with the ACPI tables).  Basically 
each PCI IRQ would have its own dedicated line.


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