From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386 Date: Mon, 23 Jul 2012 16:09:38 +0300 Message-ID: <500D4D12.1060603@redhat.com> References: <1342811652-16931-1-git-send-email-peter.maydell@linaro.org> <500A52BF.9080207@web.de> <500D42E2.4000009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , qemu-devel@nongnu.org, Marcelo Tosatti , patches@linaro.org, kvm , Alexander Graf To: Peter Maydell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9306 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752352Ab2GWNJt (ORCPT ); Mon, 23 Jul 2012 09:09:49 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 07/23/2012 03:58 PM, Peter Maydell wrote: > On 23 July 2012 13:26, Avi Kivity wrote: >> Really, "irqchip in kernel" means asynchronous interrupts - you can >> inject an interrupt from outside the vcpu thread. Obviously if the vcpu >> is sleeping you need to wake it up and that pulls in idle management. >> >> "irqchip" for x86 really means the local APIC, which has a synchronous >> interface with the cpu core. "local APIC in kernel" really is >> equivalent to "kernel idle management", "KVM_IRQ_LINE", and irqfd. The >> ioapic and pit, on the other hand, don't contribute anything to this >> (just performance). > >> So yes, ARM with and without GIC are irqchip_in_kernel, since the >> ARM<->GIC interface is asynchronous. Whether to emulate the GIC or not >> is just a performance question. > > So should we be using something other than KVM_CREATE_IRQCHIP to > ask the kernel to create a GIC model for us (and leave KVM_CREATE_IRQCHIP > as a dummy "always succeed" ioctl)? Some time ago I suggested using the parameter to KVM_CREATE_IRQCHIP to select the "irqchip type". > >> So my view is that ARM with and without kernel GIC are >> irqchip_in_kernel, since whatever is the local APIC in ARM is always >> emulated in the kernel. > > I'm not sure ARM has any equivalent to the local APIC -- the GIC > deals with everything and we don't have any equivalent division > of labour to the x86 LAPIC-IOAPIC one. It's probably a tiny part of the core with no name. The point is that the x86<->lapic interface is synchronous and bidirectional, while the lapic<->ioapic interface is asynchronous (it is still bidirectional, but not in a stop-the-vcpu way). I assume the ARM<->GIC interface is unidirectional? -- error compiling committee.c: too many arguments to function