From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srrke-0008Vi-5c for qemu-devel@nongnu.org; Thu, 19 Jul 2012 10:30:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Srrkc-0007R0-Vt for qemu-devel@nongnu.org; Thu, 19 Jul 2012 10:30:48 -0400 Received: from cantor2.suse.de ([195.135.220.15]:40166 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srrkc-0007Qv-OV for qemu-devel@nongnu.org; Thu, 19 Jul 2012 10:30:46 -0400 Message-ID: <50081A13.9000204@suse.de> Date: Thu, 19 Jul 2012 16:30:43 +0200 From: Alexander Graf MIME-Version: 1.0 References: <5007F2DF.6080807@redhat.com> <500815EC.8080204@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] passing interrupts from QEMU to KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Avi Kivity , QEMU Developers On 07/19/2012 04:16 PM, Peter Maydell wrote: > On 19 July 2012 15:13, Alexander Graf wrote: >> On 07/19/2012 02:00 PM, Peter Maydell wrote: >>> On 19 July 2012 12:43, Avi Kivity wrote: >>>> Let's make them even more similar, by removing !in_kernel_irqchip. >>> Mmm, I do rather want to just mandate use of the VGIC... >>> (somebody will probably come along later and try to get A9 >>> guests working with KVM acceleration but I don't think it >>> will be me :-)) >> Heh. I would really like to keep the !in_kernel_irqchip path (so only an EXT >> IRQ line exposed) available for PPC at least. It has helped tremendously in >> the past to be able to just throw a few debug printfs into QEMU and/or >> compare with TCG what's happening when things go wrong. > I think the difficulty here is that QEMU's in_kernel_irqchip > test is being used for two things: > * which APIC model etc should we use? > * details of the synchronous vs asynchronous model (for instance > whether halt is handled by cpus.c depends on this: cpu_thread_is_idle > always returns false if kvm_irqchip_in_kernel()) > > because for x86 these two things happen for historical reasons > to be in sync. The non-x86 architectures probably need to separate > them out so that we are always using the 'asynchronous inject' > model but may (architecture-dependent) allow the user to pick > which irqchip model gets used. Or we just remove the !in_kernel path for x86. Then everyone else can be asynchronous even for user space interrupt controller emulation. Alex