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