From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CrG-0002D0-Oa for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:35:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0CrF-0001sh-9V for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:35:34 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:55358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CrF-0001sa-0M for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:35:33 -0400 Received: by gyd12 with SMTP id 12so3101793gyd.4 for ; Sun, 04 Sep 2011 06:35:32 -0700 (PDT) Message-ID: <4E637EA2.9000503@codemonkey.ws> Date: Sun, 04 Sep 2011 08:35:30 -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> In-Reply-To: <4E636C72.4080608@redhat.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: Avi Kivity Cc: Lucas Meneghel Rodrigues , Peter Maydell , Anthony Liguori , Jan Kiszka , Marcelo Tosatti , qemu-devel , Blue Swirl , Gerd Hoffmann On 09/04/2011 07:17 AM, 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). Let's not be careful to over generalize here. Memory access is a fairly complicated thing involving multiple different types of busses, various properties (endianness, alignment, access constraints). IRQs are extremely simple. They're just single bits of information. Regards, Anthony Liguori >