From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUl0G-0004Q8-CQ for qemu-devel@nongnu.org; Wed, 16 May 2012 16:39:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUl0D-0002BU-S6 for qemu-devel@nongnu.org; Wed, 16 May 2012 16:39:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUl0D-0002B2-JM for qemu-devel@nongnu.org; Wed, 16 May 2012 16:39:21 -0400 Message-ID: <1337200755.6954.269.camel@bling.home> From: Alex Williamson Date: Wed, 16 May 2012 14:39:15 -0600 In-Reply-To: <4FB08867.9070103@ozlabs.ru> References: <4FAE1171.1010806@ozlabs.ru> <20120514015830.GC30229@truffala.fritz.box> <4FB08867.9070103@ozlabs.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH] qemu spapr-pci: added IRQ list to PCIBus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: qemu-devel@nongnu.org, Alex Graf , anthony@codemonkey.ws, kvm@vger.kernel.org On Mon, 2012-05-14 at 14:21 +1000, Alexey Kardashevskiy wrote: > On 14/05/12 11:58, David Gibson wrote: > > On Sat, May 12, 2012 at 05:29:53PM +1000, Alexey Kardashevskiy wrote: > >> There is a need for a mechanism to obtain an IRQ line number to > >> initialize End-Of-Interrupt handler. > >> > >> There is another proposed solution (commit > >> b7790763828b732059ad24ba0e64ce327563fe1a "pci: Add callbacks > >> to support retrieving and updating interrupts") which adds pci_get_irq > >> callback to every PCI bus to allow an external caller to calculate > >> IRQ number from IRQ line (ABDD). > >> > >> However it seems to be too complicated as it affects all PCI buses > >> while the only user of it is VFIO-PCI so this could be done simpler > >> by an array of 4 IRQs (lines A, B, C, D) in struct PCIBus which > >> every platform would initialize in its own way. > > > > I think you need to pin down the definition of what's going on here a > > bit better. Not all platforms have a concept of global IRQ number, > > and the usual qemu_irq model supports that. So for this function who > > is it that is defining the number space in which pci_get_irq() is > > returning values. > > > The idea is that legacy interrupt (INTx) is caught by a host driver (for example, vfio-pci). A > driver disables it and transfers to a guest. In order to enable it back, a host driver has to make > sure that the interrupt has been handled by a guest. It is done by an End-Of-Interrupt (EOI) message > sent by a guest. Then QEMU forwards the message to a host driver which enables INTx back. Right, the gap is that we can signal the interrupt in qemu, but don't know which EOI to look for to re-enable the physical device. Later we'll want to know the interrupt when we inject it so we can do so via an irqfd directly into kvm. > At the moment this mechanism - EOI callbacks - operates with global IRQ numbers, both on x86 (acpi) > and power (xics). So pci_get_irq returns only global numbers which PCIBus receives from the calling > code somehow (platform specific code knows how to initialize them, a bus cannot resolve it itself > anyway). And this is not dynamically changing information as PCI _domain_ hotplug does not exist (am > I right? :) ). It actually can change dynamically on x86 due to acpi interrupt links which allow the guest a generic way to select from a set of possible interrupt routing schemes. And of course a chipset driver could twiddle bits if it wanted as well. So, we really do need the update notifiers from my tree that this patch drops. pci_get_irq is one of the few things a qemu chipset needs to implement to get device assignment with vfio. Doing it this way with a common array in PCIBus makes the patch smaller, but I don't know that it really simplifies anything. The chipset function is trivial on x86, it's just knowing what to do that's the problem. > If we do not want pci_get_irq to return global IRQ numbers than it makes more sense to keep using > pins (A,B,C,D) plus some bus ID and not introduce any new numbers at all. How does that solve the initial problem of getting the EOI? > How can PCIBus::pci_get_irq() _callbacks_ be useful? It indicates support? Thanks, Alex