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:38:35 +0300 Message-ID: <500D53DB.5080005@redhat.com> References: <1342811652-16931-1-git-send-email-peter.maydell@linaro.org> <500A52BF.9080207@web.de> <500D42E2.4000009@redhat.com> <500D4D12.1060603@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]:45692 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752463Ab2GWNir (ORCPT ); Mon, 23 Jul 2012 09:38:47 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 07/23/2012 04:27 PM, Peter Maydell wrote: > On 23 July 2012 14:09, Avi Kivity wrote: >> On 07/23/2012 03:58 PM, Peter Maydell wrote: >>> 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". > > That seems reasonable, although we have an awkward ordering issue > in KVM as it stands: KVM_CREATE_IRQCHIP needs to be called before > we start creating VCPU threads (at the moment it is done via kvm_init) > but we don't know what kind of irqchip we want to create until the > machine model code actually creates the irqchip device, which generally > happens after the CPU object is created (and VCPU threads are created > at that point). We could fix that by moving creation of the actual > VCPU thread to vl.c after the model has been initialized. Seems to be purely a qemu problem, no? While I think it's reasonable to be flexible, in this case I think qemu ought to know all these things beforehand. > >>> 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? > > Well, strictly speaking the ARM<->GIC interface is implementation > defined, but in practice you can think of it as "the GIC controls > the IRQ and FIQ input lines to each core and uses them to signal > that an interrupt is present". There's no need for anything to > be signalled back in the other direction: the GIC will just continue > to hold IRQ asserted until the interrupt handler code writes the > relevant GIC register to indicate that the interrupt has been > handled. Okay. This agrees with my mental model of how it works. > (On a core with the virtualization extensions there are also > signals for the GIC to raise a virtual IRQ or FIQ, but we can > ignore those for KVM because we don't and can't provide the > virtualization extensions to a guest.) Yet. -- error compiling committee.c: too many arguments to function