From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0BeE-00050c-AB for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:18:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0BeD-0004QU-BD for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:18:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0BeC-0004QQ-U9 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:18:01 -0400 Message-ID: <4E636C72.4080608@redhat.com> Date: Sun, 04 Sep 2011 15:17:54 +0300 From: Avi Kivity 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 , Gerd Hoffmann 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). -- error compiling committee.c: too many arguments to function