From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: In kernel PIC support: kernel patch Date: Mon, 25 Jun 2007 18:08:26 -0400 Message-ID: <46803CDA.1010304@qumranet.com> References: <467F8E260200005A00026573@mcclure.wal.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-Reply-To: <467F8E260200005A00026573-Igcdv/6uVdMHoYOw/+koYqIwWpluYiW7@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/