From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzwIl-0006ns-1D for qemu-devel@nongnu.org; Sat, 03 Sep 2011 15:54:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzwIj-0003U5-MZ for qemu-devel@nongnu.org; Sat, 03 Sep 2011 15:54:51 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:65477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzwIj-0003Tz-H4 for qemu-devel@nongnu.org; Sat, 03 Sep 2011 15:54:49 -0400 Received: by ywf9 with SMTP id 9so3122758ywf.4 for ; Sat, 03 Sep 2011 12:54:48 -0700 (PDT) Message-ID: <4E628607.20309@codemonkey.ws> Date: Sat, 03 Sep 2011 14:54:47 -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> In-Reply-To: <4E5E1297.3050904@siemens.com> 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 08/31/2011 05:53 AM, 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. Can you provide some concrete use-cases of this? I'm not convinced this is really all that important and it seems like tremendous amounts of ugliness would be needed to support it. Regards, Anthony Liguori > > 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. > > Jan >