From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0DR0-0003kZ-K9 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 10:12:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0DQz-0006u9-MC for qemu-devel@nongnu.org; Sun, 04 Sep 2011 10:12:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0DQz-0006u3-Bi for qemu-devel@nongnu.org; Sun, 04 Sep 2011 10:12:29 -0400 Message-ID: <4E638746.6040808@redhat.com> Date: Sun, 04 Sep 2011 17:12:22 +0300 From: Avi Kivity 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> In-Reply-To: <4E638010.9010503@codemonkey.ws> 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: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Peter Maydell , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann On 09/04/2011 04:41 PM, Anthony Liguori wrote: >> 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. Pet peeve - saying something is "by definition" a hack is just rhetoric unless the definition of device state is "something that cannot be extracted and externalized". Let's avoid this. In fact it's exactly what we do with the memory API. Memory routing is part of device state, yet we expose it to the memory API and let it do its thing instead of going through the hierarchy on every single memory access. Whether it's worthwhile to do this for interrupts as well depends on how common the situation is and what we gain from it. We can only do this if the routing is semi-static (depends only on other state but not the actual interrupt) - probably the only exception to this is the "least priority" mode which means the last leg cannot be computed statically. I agree the gain is low if we limit ourselves to 440fx, but if we add interrupt remapping it becomes considerably more complicated to do this backward path computation. -- error compiling committee.c: too many arguments to function