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. > ------------------------------------------------------------------------- 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 https://lists.sourceforge.net/lists/listinfo/kvm-devel
