Re: In kernel PIC support: kernel patch

Gregory Haskins
2007-06-25T13:43:02Z

On Sat, 2007-06-23 at 20:41 +0300, Avi Kivity wrote:
> Dong, Eddie wrote:
> > 3: IOAPIC position
> > Though it looks like neutral to have this one in user or kernel
> > space,
> > but I'd like to suggest we only support one model. Considering future
> > VT-d
> > case, hypervisor need to inject an IRQ directly in KVM (still thru
> > IOAPIC)
> > without going to user level, so probably moving IOAPIC to kernel is good
> >
> > in this point.
> >
>
> Even 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.

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)

Thoughts?

> 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? 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.