From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QypLy-0007Bl-FC for qemu-devel@nongnu.org; Wed, 31 Aug 2011 14:17:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QypLw-0007pT-UA for qemu-devel@nongnu.org; Wed, 31 Aug 2011 14:17:34 -0400 Received: from thoth.sbs.de ([192.35.17.2]:30766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QypLw-0007pL-Ed for qemu-devel@nongnu.org; Wed, 31 Aug 2011 14:17:32 -0400 Message-ID: <4E5E7AB8.9060304@siemens.com> Date: Wed, 31 Aug 2011 20:17:28 +0200 From: Jan Kiszka 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: Content-Type: text/plain; charset=UTF-8 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: Blue Swirl Cc: Lucas Meneghel Rodrigues , Peter Maydell , Anthony Liguori , Marcelo Tosatti , qemu-devel , Avi Kivity , Gerd Hoffmann On 2011-08-31 19:41, Blue Swirl wrote: > 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 >> (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 >> 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. > > 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. It already works in practice (based on a hack and minus IRQ router state updates) for x86 PCI device pass-through. At least I don't want this upstream but instead a generic solution. The ability to skip IRQ routers also in pure user space device model scenarios is a useful by-product. > >> 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. Well, the backward links would then be moved to that global IRQ manager. It's just moving the data management, but if it turns out to allow a cleaner device design, I would surely not vote against it. But that manager must support lazy updates as well because we cannot call it from kernel space for each and every event. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux