From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CxB-00057B-M8 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:41:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0CxA-0002a1-FP for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:41:41 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:52395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CxA-0002Zx-Cw for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:41:40 -0400 Received: by yxt3 with SMTP id 3so2160853yxt.4 for ; Sun, 04 Sep 2011 06:41:39 -0700 (PDT) Message-ID: <4E638010.9010503@codemonkey.ws> Date: Sun, 04 Sep 2011 08:41:36 -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> In-Reply-To: <4E637EEA.1030502@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: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. The PCI bus *is* the I/O APIC for all intents and purposes. Being able to ask the i440fx for the interrupt corresponding to a device is a very simple task that involves no generic code. That's more than enough to support device assignment. Why overcomplicate things when the problem can be solved robustly with most likely a 10 line function? Regards, Anthony Liguori > > Jan >