From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Date: Mon, 23 Sep 2013 18:34:01 +0000 Subject: Re: [PATCH 1/2] KVM: Implement default IRQ routing Message-Id: <20130923183401.GE1445@redhat.com> List-Id: References: <20130917091840.GA12722@iris.ozlabs.ibm.com> <20130922123253.GL25202@redhat.com> <20130923112414.GA32420@iris.ozlabs.ibm.com> In-Reply-To: <20130923112414.GA32420@iris.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paul Mackerras Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Alexander Graf , Benjamin Herrenschmidt On Mon, Sep 23, 2013 at 09:24:14PM +1000, Paul Mackerras wrote: > On Sun, Sep 22, 2013 at 03:32:53PM +0300, Gleb Natapov wrote: > > On Tue, Sep 17, 2013 at 07:18:40PM +1000, Paul Mackerras wrote: > > > This implements a simple way to express the case of IRQ routing where > > > there is one in-kernel PIC and the system interrupts (GSIs) are routed > > > 1-1 to the corresponding pins of the PIC. This is expressed by having > > > kvm->irq_routing = NULL with a skeleton irq routing entry in the new > > > kvm->default_irq_route field. > > > > > > This provides a convenient way to provide backwards compatibility when > > > adding IRQ routing capability to an existing in-kernel PIC, such as the > > > XICS emulation on powerpc. > > > > > Why not create simple 1-1 irq routing table? It will take a little bit > > more memory, but there will be no need for kvm->irq_routing = NULL > > special handling. > > The short answer is that userspace wants to use interrupt source > numbers (i.e. pin numbers for the inputs to the emulated XICS) that > are scattered throughout a large space, since that mirrors what real > hardware does. More specifically, hardware divides up the interrupt > source number into two fields, each of typically 12 bits, where the > more significant field identifies an "interrupt source unit" (ISU) and > the less significant field identifies an interrupt within the ISU. > Each PCI host bridge would have an ISU, for example, and there can be > ISUs associated with other things that attach directly to the > interconnect fabric (coprocessors, cluster interconnects, etc.). > > Today, QEMU creates a virtual ISU numbered 1 for the emulated PCI host > bridge, which means for example that virtio devices get interrupt pin > numbers starting at 4096. > > So, I could have increased KVM_IRQCHIP_NUM_PINS to some multiple of > 4096, say 16384, which would allow for 3 ISUs. But that would bloat > out struct kvm_irq_routing_table to over 64kB, and if I wanted 1-1 > mappings between GSI and pins for all of them, the routing table would > be over 960kB. > Yes, this is not an option. GSI is just a cookie for anything but x86 non MSI interrupts. So the way to use irq routing table to deliver XICS irqs is to register GSI->XICS irq mapping and by triggering "GSI", which is just an arbitrary number, userspace tells kernel that XICS irq, that was registered for that GSI, should be injected. > There is a compatibility concern too -- if I want existing userspace > to run, I would have to create 1-1 default mappings for at least the > first (say) 4200 pins or so, which would use up about 294kB. That > really doesn't seem worth it compared to just using the null routing > table pointer to indicate an unlimited 1-1 mapping. > Let me check that I understand you correctly. Exiting userspace already uses XICS irq directly and now you want to switch this interface to use irq routing. New userspace will register GSI->XICS irq mapping like described above, this is what [2/2] does. Is this correct? -- Gleb.