From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0DAB-0007tE-1S for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:55:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0DA9-0004Y3-Op for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:55:06 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:57416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0DA9-0004X5-K8 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:55:05 -0400 Received: by gxk26 with SMTP id 26so2813443gxk.4 for ; Sun, 04 Sep 2011 06:55:04 -0700 (PDT) Message-ID: <4E638336.6000205@codemonkey.ws> Date: Sun, 04 Sep 2011 08:55:02 -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> <4E636C72.4080608@redhat.com> <4E6370FD.2010703@web.de> <4E637F53.6010102@codemonkey.ws> <4E638044.5020709@web.de> In-Reply-To: <4E638044.5020709@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:42 AM, Jan Kiszka wrote: > On 2011-09-04 15:38, Anthony Liguori wrote: >>> With current kvm device assignment it's mandatory as it only support >>> kernel/kernel IRQ delivery. Only vfio's eventfds will make it optional >>> (but still highly desirable). >> >> It's not mandatory. All you need to be able to do is calculate the APIC >> IRQ for a given PCI device interrupt. > > ...and establish notifies for changes along this line. And allow to > update intermediate states on access. Again, this is all in a single layer. > >> That doesn't mean we need to be >> able to do arbitrary interrupt resolution in generic code. > > We will likely have to solve the same problem on none x86 as well. But we're already seeing the that device assignment problem is very different on other platforms. Given multiple well known architectures, yes, it makes sense to write generic code to handle both. But we shouldn't just assume that just because we have one use-case that it generalizes to arbitrarily complex use-cases. An IRQ routing table sounds good in theory but in practice it's just not that simple. Image a simple device with an output pin that is high when there is data to read. It looks and smells like an IRQ but there's nothing to say that it's ever going to be routed to the CPU as a level interrupt. It may be handled entirely within another device for a certain platform. But in another platform, it may actually be routed as a level triggered interrupt to the CPU. In fact, as we do more pin level modelling, we'll run into a lot of scenarios like this. Over generalizing is just going to box us into this narrow view of anything that's a single bit of information being directly routable to a CPU. >> There is potentially tremendous complexity here because you'll have to >> bake all interrupt rerouting logic into a declarative API and/or call >> into generic code to update routing tables. Given the fact that we >> can't even generically refer to a device reliably today, this is would >> be a daunting task. >> >> We're making this all more complicated than it needs to be. > > We can't discuss the problem away, sorry. "We may need at some point in the future" is not a sufficient justification either. If we want to talk about concrete scenarios, fine. I'm all for doing what we need to do to support things. But unless there's an absolutely compelling need to introduce a global interrupt routing table, I think we're much better off handling it as special cases. Regards, Anthony Liguori > Jan >