From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srp8u-0007QI-2N for qemu-devel@nongnu.org; Thu, 19 Jul 2012 07:43:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Srp8o-0006tZ-9u for qemu-devel@nongnu.org; Thu, 19 Jul 2012 07:43:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Srp8n-0006tS-W9 for qemu-devel@nongnu.org; Thu, 19 Jul 2012 07:43:34 -0400 Message-ID: <5007F2DF.6080807@redhat.com> Date: Thu, 19 Jul 2012 14:43:27 +0300 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: QEMU Developers , Alexander Graf On 07/19/2012 02:14 PM, Peter Maydell wrote: > > Basically I'm not sure why there's all this variety here, > or why x86 does things differently for in-kernel irqchip > versus not -- I would have expected that the only difference > for an in-kernel irqchip is that there are more interrupt > lines. Kicking the CPU out of the kernel in particular seems > a very roundabout way of telling it about an interrupt, > but I assume there's a rationale for doing it that way... Non-in-kernel irqchip is synchronous; everything must be executed in vcpu context. This is because the kernel does not queue any interrupts, rather userspace requests an "interrupt window" (an instruction boundary where the vcpu is ready for interrupt injection) and then qemu injects that interrupt. In-kernel irqchip added the logic for queueing interrupts, and is completely asynchronous. You can queue an interrupt from a different thread, the kernel will inject it when the vcpu is ready. > > The way I'm thinking about handling this for ARM is just > to have both the irqchip and no-irqchip approaches be > roughly the same: the device code just makes the relevant > KVM ioctl to inject interrupts (the semantics of the irq > number change for irqchip vs not irqchip but the general > behaviour is the same), and we never call cpu_interrupt() > if KVM is enabled. Is there any reason that wouldn't work? > Let's make them even more similar, by removing !in_kernel_irqchip. -- error compiling committee.c: too many arguments to function