From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EEK-0006wX-06 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:03:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0EEJ-0007US-2l for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:03:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EEI-0007UK-PA for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:03:27 -0400 Message-ID: <4E639337.2050209@redhat.com> Date: Sun, 04 Sep 2011 18:03:19 +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> <4E638746.6040808@redhat.com> <4E638EA7.8040806@codemonkey.ws> In-Reply-To: <4E638EA7.8040806@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 05:43 PM, Anthony Liguori wrote: >> 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. > > > Likewise, I would prefer to avoid stating that something is a hard > requirement in the absence of concrete use-cases. Agree. But let's not fight rhetoric with rhetoric. I also agree that if it were just the 440fx, then we could have a private channel between device assignment and the ioapic. But if there are more use cases, it calls for a generic solution. > I do think the definition of device state is more or less something > that is opaque and owned by the device. The more we externalize the > device state, the more we have to deal with compatibility (even if > it's just internal compatibility). This makes modularity hard because > there's too many things with complex dependencies. That depends on the number of special cases we'll see. I really have no insight here. > >> 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. > > Yes, and the memory API is complicated and invasive :-) But it's > worth it at the end of the day (although I think it could be > simplified at the expensive of not allowing as much flattening). (we should have spent a few hours at kf2011 to convince you that this is impossible) > > What I'm concerned about is an attempt to globally track IRQ routing. > I can imagine constructing a board where you have two simple devices > that have level triggered interrupts and wanting to tie them to a > single input pin. A simple OR gate would be sufficient to do this. > Having to make an OR gate an IRQ router seems like far too much > complexity to me. Depends on the API. If Pin has a method pin_add_tristate_input(), then it becomes trivial. > I think we need to strive to keep simple things simple. Too late. -- error compiling committee.c: too many arguments to function