Re: In kernel PIC support: kernel patch

Gregory Haskins
2007-06-25T14:10:13Z

On Mon, 2007-06-25 at 21:54 +0800, Dong, Eddie wrote:
>
> >-----Original Message-----
> >From: Gregory Haskins [mailto:ghaskins@novell.com]
> >Sent: 2007年6月25日 21:43
> >To: avi@qumranet.com
> >Cc: Dong, Eddie; kvm-devel@lists.sourceforge.net
> >Subject: Re: [kvm-devel] In kernel PIC support: kernel patch
> >
> >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.
>
> Basically we are talking about same thing. calling kvm_apicbus_send or
> raise a virtual ioapic pin is basically same. The minor different is who does
> the translation from pin to APIC message, device model or IOAPIC model.
>
> Using IOAPIC pin probably makes PV driver writter a little bit easier and
> may be reused by other VMM easily in future.

I fully agree with everything you say here. I just wanted to point out
that pv-devices dont have a hard-requirement for an IOAPIC connection in
case it makes something easier for someone. ;)

>
> >
> >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)
>
> Yes, all you mentioned here is correct, but it doesn;t impact the
> necessity of moving IOAPIC to kernel, see below.
>
> >
> >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
>
> No, the IOAPIC is in kernel, but some device such as IDE are in user while others
> are in kernel such as pv NIC.
>
> Due to this, a kernel pv driver will ask for IOAPIC service, so we have to keep
> it in kernel, otherwise we have to go back to user when kernel device fires, which
> is very slow.
>
> But, like you mentio> it helps, but then 1: we have to implement MSI now, 2: a little bit more complicated
> in writting pv driver.

Ok, I think I understand what Avi was saying now. The "or" operation is
in reference to a shared irq-line coming into the IOAPIC. e.g. We need
to maintain a logical OR against the current level of a particular line.
I thought he was talking about maintaining internal IOAPIC state between
user/kern, which is probably messier than two IOAPICs. ;)

>
> >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
>
> It can, but a little bit more complicated, and probably unable to live
> migration between KVM and Qemu since Qemu only has one IOAPIC.

Good point, but is that a design requirement?

>
> >infrastructure standpoint, and is much cleaner IMHO. If you were
> >talking about a different scenario. please clarify.
> >
>
> Thx,eddie

-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net