From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0ETi-0001oA-4H for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:19:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0ETh-0001ot-0c for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:19:22 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:33725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0ETg-0001oj-QV for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:19:20 -0400 Received: by gwb19 with SMTP id 19so2763967gwb.4 for ; Sun, 04 Sep 2011 08:19:20 -0700 (PDT) Message-ID: <4E6396F6.9040200@codemonkey.ws> Date: Sun, 04 Sep 2011 10:19:18 -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> <4E638746.6040808@redhat.com> <4E638EA7.8040806@codemonkey.ws> <4E639337.2050209@redhat.com> In-Reply-To: <4E639337.2050209@redhat.com> 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: Avi Kivity Cc: Lucas Meneghel Rodrigues , Peter Maydell , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann On 09/04/2011 10:03 AM, Avi Kivity wrote: > On 09/04/2011 05:43 PM, Anthony Liguori wrote: >>> 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) I don't mean for RAM, but for device I/O. Instead of implementing it_shift in the core API, you could implement it_shift by having a device that takes an input MemoryRegion and an output MemoryRegion and implements the it_shift logic. I think endianness could also be handled this way too. For stuff like coalesced I/O and eventfds, I understand the difficulties. > >> >> 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. See my self-reply to Jan. I think there's a reasonable middle ground using an IrqRouter interface. Regards, Anthony Liguori