From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyonC-0002VD-JX for qemu-devel@nongnu.org; Wed, 31 Aug 2011 13:41:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QyonB-0000z6-96 for qemu-devel@nongnu.org; Wed, 31 Aug 2011 13:41:38 -0400 Received: from mail-qw0-f47.google.com ([209.85.216.47]:36443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyonB-0000z1-6o for qemu-devel@nongnu.org; Wed, 31 Aug 2011 13:41:37 -0400 Received: by qwh5 with SMTP id 5so752518qwh.34 for ; Wed, 31 Aug 2011 10:41:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E5E1297.3050904@siemens.com> 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> From: Blue Swirl Date: Wed, 31 Aug 2011 17:41:16 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 , Avi Kivity , Gerd Hoffmann On Wed, Aug 31, 2011 at 10: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 > =C2=A0 (that would be possible via QOM just using forward links) Why, only for b)? This is not possible with real hardware. > b) skip updating the states of IRQ routers in the common case, just > =C2=A0 signaling directly the sink from the source (to allow in-kernel IR= Q > =C2=A0 delivery or to skip taking some device locks). Whenever some route= r > =C2=A0 is queried for its current IRQ line state, it would have to ask th= e > =C2=A0 preceding IRQ source for its state. So we need a backward link. I think this would need pretty heavy changes everywhere. At board level the full path needs to be identified and special versions of IRQs installed along the way. The routers would need to use callbacks to inform other parties about routing changes. > 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. Perhaps a global IRQ manager could help. It would keep track of the whole IRQ matrix, what are input (x axis) and output (y axis) states and what each matrix node (router state) looks like (or able to compute) if asked. I don't think backward links would be needed with this approach.