From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StHNc-0006JD-N0 for qemu-devel@nongnu.org; Mon, 23 Jul 2012 08:04:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StHNY-0004VO-58 for qemu-devel@nongnu.org; Mon, 23 Jul 2012 08:04:52 -0400 Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:51172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StHNX-0004VH-Pi for qemu-devel@nongnu.org; Mon, 23 Jul 2012 08:04:48 -0400 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Jul 2012 13:04:45 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6NC4Kiw2662504 for ; Mon, 23 Jul 2012 13:04:21 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6NBhvcf001402 for ; Mon, 23 Jul 2012 07:43:57 -0400 Date: Mon, 23 Jul 2012 14:04:18 +0200 From: Cornelia Huck Message-ID: <20120723140418.76d8f874@BR9GNB5Z> In-Reply-To: <500AABC8.7080406@web.de> References: <1342811652-16931-1-git-send-email-peter.maydell@linaro.org> <500A52BF.9080207@web.de> <500A730F.8040604@web.de> <500A7A02.3050301@web.de> <500A8303.8020903@web.de> <500A8DAE.3040909@web.de> <500AA21E.9050506@web.de> <500AABC8.7080406@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , kvm , patches@linaro.org, Marcelo Tosatti , qemu-devel@nongnu.org, Alexander Graf , Avi Kivity On Sat, 21 Jul 2012 15:16:56 +0200 Jan Kiszka wrote: > On 2012-07-21 14:57, Peter Maydell wrote: > > On 21 July 2012 13:35, Jan Kiszka wrote: > >> On 2012-07-21 14:17, Peter Maydell wrote: > >>> You still haven't really explained why we can't just ignore irqfd > >>> for now. I don't see how it would particularly affect the design > >>> of the kernel implementation very much, and the userspace interface > >>> seems to just be an extra ioctl. > >> > >> I bet you ignored MSI so far. Physical IRQ lines are just a part of the > >> whole picture. How are MSIs delivered on the systems you want to add? > > > > You're using random acronyms without defining them again. It looks > > as if MSI is a PCI specific term. That would seem to me to fall > > under the heading of "routing across a board model" which we can't > > do anyway, because you have no idea how this all wired up, it > > will depend on the details of the SoC and the PCI controller. > > For sure you can. You need to discover those wiring, cache it, and then > let the source inject to the final destination directly. See the INTx > routing notifier and pci_device_route_intx_to_irq from [1] for that > simplistic approach we are taking on the x86/PC architecture. > >>>> Once you support the backend (KVM_SET_GSI_ROUTING + KVM_IRQ_LINE), > >>>> adding irqfd is in fact simple. > >>> > >>> I don't really understand where KVM_SET_GSI_ROUTING comes into > >>> this -- the documentation is a bit opaque. It says "Sets the GSI > >>> routing table entries" but it doesn't define what a GSI is or > >>> what we're routing to where. Googling suggests GSI is an APIC > >>> specific term so it doesn't sound like it's relevant for non-x86. > >> > >> As I said before: "GSI" needs to be read as "physical or virtual IRQ > >> line". The virtual ones can be of any source you define, irqfd is just one. > > > > What's a virtual irq line in this context? We're modelling a physical > > bit of hardware which has N interrupt lines, so I'm not sure what > > a virtual irq line would be or how it would appear to the guest... > > A virtual line is an input of the in-kernel IRQ router you configure via > SET_GSI_ROUTING. A physical line is a potential output of it that goes > into some in-kernel interrupt controller model. It can also be an > interrupt message sent to a specific CPU - provided the arch supports > such a delivery protocol. > > Of course, the current router was modeled after x86 and ia64. So I > wouldn't be surprised if some ARM system configuration cannot be > expressed this way. Then we need to discuss reasonable extensions. But > it should provide a sound foundation at least. OK, so I was reading through this thread since I want to add irqfd support for s390, but we don't have any kind of "irqchip". The understanding I got so far is that !s390 architectures have some kind of mechanism that allows them to "route" an interrupt between a device and a cpu, meaning that there's a fixed tie-in between a device and a cpu. If that's correct, I don't see how to model irqfds via this irqchip infrastructure for s390. Here's in a nutshell how (external and I/O) interrupts work on s390: - Interrupts have an internal prioritation, that means different types of interrupts (external, I/O, machine check, ...) take precedent over other types - External and I/O interrupts are "floating", i. e. they are not tied to a specific cpu, but can be delivered to any cpu that has external resp. I/O interrupts enabled - Interrupts take payload with them that defines which device they are for So, for example, if a specific subchannel (=device) has pending status and an I/O interrupt is to be generated, this interrupt remains pending until an arbitrary cpu is enabled for I/O interrupts. If several cpus are enabled for I/O interrupts, any of them may be interrupted. When an I/O interrupt is delivered on a cpu, the cpu's lowcore contains the interrupt payload which defines the subchannel (=device) the interrupt is for. Any idea on how this architecture can be married with the irqchip concept is welcome. If all else fails, would a special irqfd concept for !irqchip be acceptable? Cornelia