From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Wfe-0006Em-Ld for qemu-devel@nongnu.org; Mon, 05 Sep 2011 06:44:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0Wfc-0002L6-A8 for qemu-devel@nongnu.org; Mon, 05 Sep 2011 06:44:54 -0400 Received: from mail-ew0-f45.google.com ([209.85.215.45]:65364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Wfc-0002Kx-4q for qemu-devel@nongnu.org; Mon, 05 Sep 2011 06:44:52 -0400 Received: by ewy24 with SMTP id 24so2338924ewy.4 for ; Mon, 05 Sep 2011 03:44:51 -0700 (PDT) Date: Mon, 5 Sep 2011 12:44:46 +0200 From: "Edgar E. Iglesias" Message-ID: <20110905104446.GD26890@edde.se.axis.com> References: <4E5D39C8.5020205@web.de> <4E5E1297.3050904@siemens.com> <4E628607.20309@codemonkey.ws> <4E636B56.9070808@web.de> <4E637E06.9020206@codemonkey.ws> <4E637EEA.1030502@web.de> <4E638010.9010503@codemonkey.ws> <4E6381D9.5060709@web.de> <4E6383CB.3070102@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6383CB.3070102@codemonkey.ws> 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: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Peter Maydell , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Avi Kivity , Gerd Hoffmann On Sun, Sep 04, 2011 at 08:57:31AM -0500, Anthony Liguori wrote: > On 09/04/2011 08:49 AM, Jan Kiszka wrote: > > On 2011-09-04 15:41, Anthony Liguori wrote: > >> On 09/04/2011 08:36 AM, Jan Kiszka wrote: > >>> On 2011-09-04 15:32, Anthony Liguori wrote: > >>>> 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. > >>> > >>> See it as you like, but we need the support, not only for device > >>> assigment. And I do not see any gain it hacking this instead of > >>> designing it. > >> > >> You can design a hack but it's still a hack. > >> > >> Device state belongs in devices. Trying to extract device state > >> (interrupt routing paths) and externalizing it is by definition a hack. > >> > >> Having some sort of global interrupt routing table is just going to add > >> a layer of complexity for very little obvious gain. > > > > It's not yet decided how the problem is solved. A global interrupt > > matrix is just one proposal, another option is to extend the pin model > > in a way that supports routing change notifiers and backward polling. > > If that's all you need, then you really just want notification on socket > changes. Backwards polling can be achieved by just adding state to the > Pin (which I full heartedly support). I'm not a fan of this backwards thing, but seeing the options available, it might be the simplest way forward. I agree that the global interrupt manager sounds like overkill... Cheers