From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [kvm-ia64-devel] IRQ assignment Date: Wed, 21 May 2008 19:34:34 +0300 Message-ID: <48344F1A.8090305@qumranet.com> References: <51CFAB8CB6883745AE7B93B3E084EBE201BCC43D@pdsmsx412.ccr.corp.intel.com> <4834459B.1090900@qumranet.com> <51CFAB8CB6883745AE7B93B3E084EBE201BCC43E@pdsmsx412.ccr.corp.intel.com> <1284E411-576E-498A-A1D2-4B9F37E72533@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Xu, Anthony" , Jes Sorensen , kvm-ia64@vger.kernel.org, "Zhang, Xiantao" , kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194]:53301 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758149AbYEUQeh (ORCPT ); Wed, 21 May 2008 12:34:37 -0400 In-Reply-To: <1284E411-576E-498A-A1D2-4B9F37E72533@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: > > On May 21, 2008, at 6:07 PM, Xu, Anthony wrote: > >> Avi Kivity wrote: >>> Xu, Anthony wrote: >>>> Xiantao and I have found the root cause, >>>> Qemu emulates PIIX chipset, all pci devices can only use irq 10.11, >>>> which is confiured inside chipset interrupt routing table. Even >>>> though IOAPIC have 24 interrupt pins. >>>> While KVM/IA64 use the same Guest Firmware with what XEN/IA64 which >>>> use different "interrupt routing algorithm". >>>> Means the pci device irq doesn't match between qemu and Guest >>>> Firmware in KVM/IA64. So guest didn't get pci device interrupt. >>>> >>>> Obviously there are two ways to fix it. >>>> 1. modify qemu side, all pci devices use irq larger than or equal to >>>> 16, we need to come out an algorithm to calculate irq from pci >>>> device(bus number,device number, function number), >>>> then we also need to modify IA32 Guest BIOS to present the same >>>> pci device irq (use same algorithm) to guest OS. Avi seems not want >>>> to modify qemu a lot. >>>> >>>> 2. modify IA64 guest firmware, two pros, (1)all pci devices use only >>>> 10,11 two irqs, so if there are many pci device, there are a lot of >>>> interrupt sharing, which impact performance negatively >>>> (2) We need to maintain two versions fo IA64 guest firmwares, one >>>> for KVM/IA64, the other for XEN/IA64, which is not what I want. >>>> >>>> >>>> What's your suggestion? >>>> >>>> >>> >>> Allowing qemu to use all ioapic interrupt pins will reduce interrupt >>> sharing on x86, which is a good thing, so I prefer the first option >>> too. >> >> >> Thanks for your support, I preper option #1, >> Any suggestion for the mapping from BDF to irq. >> >> In XEN both in IA64/IA32, >> >> BIOS provides a 48 pin IOAPIC ( usually it is 24) to reduce irq sharing. > > Most mainboards these days provide two IOAPICs, which would sum up to > 48 again. I think that should be the preferred way of implementing it > virtually too. > I agree. ia64 has a preference for a single 48-pin ioapic for Xen compatibility, but x86 and ia64 needn't be exactly equal. On the other hand, adding a new ioapic will be more difficult than extending an existing one. On yet another hand, two ioapics (each with its own lock) will improve scaling. On the fourth hand (anyone for Bridge?), if we hit ioapic scalability problems, each pin should have its own lock. > The idea is great! I tried extending the IRQ logic to a "full IOAPIC" > myself recently, but failed miserably. The biggest hurdle is that > currently the code is reversed in qemu. If an interrupt occurs, the > PIC is asked if it's destined to go there and if not it gets rerouted > to the IOAPIC. Unfortunately this breaks with IRQs > 16. Shouldn't each irq be routed to *both* chips, and the OS disables one or the other? -- error compiling committee.c: too many arguments to function