Re: In kernel PIC support: kernel patch

Avi Kivity
2007-06-25T22:08:26Z

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.