From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Cu7-0003XS-3s for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:38:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0Cu5-0002A7-Vz for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:38:31 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:61213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Cu5-0002A2-Ta for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:38:29 -0400 Received: by gxk26 with SMTP id 26so2809777gxk.4 for ; Sun, 04 Sep 2011 06:38:29 -0700 (PDT) Message-ID: <4E637F53.6010102@codemonkey.ws> Date: Sun, 04 Sep 2011 08:38:27 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5D39C8.5020205@web.de> <4E5E1297.3050904@siemens.com> <4E636C72.4080608@redhat.com> <4E6370FD.2010703@web.de> In-Reply-To: <4E6370FD.2010703@web.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Lucas Meneghel Rodrigues , Peter Maydell , Anthony Liguori , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Gerd Hoffmann On 09/04/2011 07:37 AM, Jan Kiszka wrote: > On 2011-09-04 14:17, Avi Kivity wrote: >> On 08/31/2011 01:53 PM, Jan Kiszka wrote: >>> On 2011-08-31 10:25, Peter Maydell wrote: >>>> On 30 August 2011 20:28, Jan Kiszka wrote: >>>>> Yes, that's the current state. Once we have bidirectional IRQ >>> links in >>>>> place (pushing downward, querying upward - required to skip IRQ >>> routers >>>>> for fast, lockless deliveries), that should change again. >>>> >>>> Can you elaborate a bit more on this? I don't think anybody has >>>> proposed links with their own internal state before in the qdev/qom >>>> discussions... >>> >>> That basic idea is to allow >>> >>> a) a discovery of the currently active IRQ path from source to sink >>> (that would be possible via QOM just using forward links) >>> >>> b) skip updating the states of IRQ routers in the common case, just >>> signaling directly the sink from the source (to allow in-kernel IRQ >>> delivery or to skip taking some device locks). Whenever some router >>> is queried for its current IRQ line state, it would have to ask the >>> preceding IRQ source for its state. So we need a backward link. >>> >>> We haven't thought about how this could be implemented in details yet >>> though. Among other things, it heavily depends on the final QOM design. >>> >> >> Looks like a similar path to the memory API. A declarative description >> of the interrupt hierarchy allows routes to be precalculated and flattened. >> >> (here it's strictly an optimization; with the memory API it's a >> requirement since kvm requires a flattened representation, and tcg is >> greatly simplified by it). > > With current kvm device assignment it's mandatory as it only support > kernel/kernel IRQ delivery. Only vfio's eventfds will make it optional > (but still highly desirable). It's not mandatory. All you need to be able to do is calculate the APIC IRQ for a given PCI device interrupt. That doesn't mean we need to be able to do arbitrary interrupt resolution in generic code. There is potentially tremendous complexity here because you'll have to bake all interrupt rerouting logic into a declarative API and/or call into generic code to update routing tables. Given the fact that we can't even generically refer to a device reliably today, this is would be a daunting task. We're making this all more complicated than it needs to be. Regards, Anthony Liguori > Jan >