From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EcD-0005IY-4w for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:28:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0EcA-0003JF-Pb for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:28:09 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:44274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EcA-0003Iw-IV for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:28:06 -0400 Received: by qyk31 with SMTP id 31so2601947qyk.4 for ; Sun, 04 Sep 2011 08:28:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E638EA7.8040806@codemonkey.ws> 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> From: Blue Swirl Date: Sun, 4 Sep 2011 15:27:46 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 , Jan Kiszka , Avi Kivity , Gerd Hoffmann On Sun, Sep 4, 2011 at 2:43 PM, Anthony Liguori wro= te: > On 09/04/2011 09:12 AM, Avi Kivity wrote: >> >> 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. > > Likewise, I would prefer to avoid stating that something is a hard > requirement in the absence of concrete use-cases. > > I do think the definition of device state is more or less something that = is > opaque and owned by the device. =C2=A0The more we externalize the device = state, > the more we have to deal with compatibility (even if it's just internal > compatibility). =C2=A0This makes modularity hard because there's too many= things > with complex dependencies. > >> 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 :-) =C2=A0But it's wo= rth it > at the end of the day (although I think it could be simplified at the > expensive of not allowing as much flattening). > >> 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. > > If we start with a simple interface that works for the i440fx and then > expand it as we support more layers, I think we'll be okay. > > What I'm concerned about is an attempt to globally track IRQ routing. =C2= =A0I 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.= =C2=A0A > simple OR gate would be sufficient to do this. =C2=A0Having to make an OR= gate an > IRQ router seems like far too much complexity to me. For the simple OR gate this is a downside of course, but I don't see a way to avoid it, same with the memory API or other APIs that need to cater for wide variety of needs. > I think we need to strive to keep simple things simple. If the APIs need only minor changes, the changes to the devices would not be so big. At this point I think your router API would only need the change callback to support the matrix and Pin should be compatible. > Regards, > > Anthony Liguori > >