From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0DCa-00011x-Ez for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:57:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0DCZ-0004lR-E1 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:57:36 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:63505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0DCZ-0004jB-97 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:57:35 -0400 Received: by yih10 with SMTP id 10so3303002yih.4 for ; Sun, 04 Sep 2011 06:57:34 -0700 (PDT) Message-ID: <4E6383CB.3070102@codemonkey.ws> Date: Sun, 04 Sep 2011 08:57:31 -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> <4E637E06.9020206@codemonkey.ws> <4E637EEA.1030502@web.de> <4E638010.9010503@codemonkey.ws> <4E6381D9.5060709@web.de> In-Reply-To: <4E6381D9.5060709@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 , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Gerd Hoffmann 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). If that's all you're proposing, than I'm entirely happy with it :-) I'm happy with that because all of the route detection logic can live outside of the devices which at least contains the complexity. Regards, Anthony Liguori