From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Com-0001JC-2V for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:33:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0Coj-0001dY-PO for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:32:59 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:54825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Coj-0001dH-Lw for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:32:57 -0400 Received: by gwb19 with SMTP id 19so2737271gwb.4 for ; Sun, 04 Sep 2011 06:32:57 -0700 (PDT) Message-ID: <4E637E06.9020206@codemonkey.ws> Date: Sun, 04 Sep 2011 08:32:54 -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> <4E628607.20309@codemonkey.ws> <4E636B56.9070808@web.de> In-Reply-To: <4E636B56.9070808@web.de> 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 09/04/2011 07:13 AM, Jan Kiszka wrote: > On 2011-09-03 21:54, Anthony Liguori wrote: >> 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. > > INTx support for device assignment, vhost, or any other future in-kernel > IRQ sources. I prefer to not think of IRQs as special things. They're just single bits of information that flow through the device model. Having a higher level representation that understands something like paths seems wrong to me. I'd prefer to treat things like device assignment as a hack. You just need code that can walk the device tree to figure out the path (which is not generic code, it's very machine specific). Then you tell the kernel the resolution of the path and are otherwise completely oblivious in userspace. Regards, Anthony Liguori