From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses Date: Thu, 18 Oct 2012 17:25:21 +0200 Message-ID: <50801F61.50700@redhat.com> References: <1350173065-35350-1-git-send-email-c.dall@virtualopensystems.com> <507F172D.2030802@suse.de> <20121017221022.GA4333@bloggs.ozlabs.ibm.com> <1350518331.4678.114.camel@pasglop> <27A2A5B6-130B-4F8D-8B29-E94C3497DC00@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoffer Dall , Benjamin Herrenschmidt , Paul Mackerras , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kvm-ppc , Peter Maydell To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40626 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755762Ab2JRPZi (ORCPT ); Thu, 18 Oct 2012 11:25:38 -0400 In-Reply-To: <27A2A5B6-130B-4F8D-8B29-E94C3497DC00@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 10/18/2012 03:49 PM, Alexander Graf wrote: > > On 18.10.2012, at 15:48, Christoffer Dall wrote: > >> On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt >> wrote: >>> On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote: >>>> >>>> With the XICS, there are two types of irqchip: a source controller and >>>> a presentation controller. There is one presentation controller per >>>> vcpu and typically one source controller per PCI host bridge (a source >>>> controller can manage multiple sources). The "buid" above is >>>> basically an identifier for a source controller. >>>> >>>> So with the above, it would be quite easy to add new types and >>>> arguments for them. >>> >>> The only possible issue is that afiak, the ioctl number depends on the >>> structure size, no ? If it does, then we should add some padding to the >>> union to leave room for new types. >>> >> It sounds overall ok to me, however, Peter Maydell pointed out that >> QEMU is architected in such a way that creating the IRQ chip happens >> before QEMU knows how the chip fits with the model it is emulating and >> therefore lacks bits of information that we require for initializing >> the irq chip. >> >> Specifically on ARM the information needed is the base address of a >> hardware peripheral, which is virtualization aware, and is mapped >> directly into the guest's physical address space. >> >> One could argue that's not a concern for designing a good kernel api, >> but on the other hand, qemu is already quite a large system on its >> own, and we have to be practical. >> >> Another alternative is to just let qemu init the device, later give >> the base address and check before each execution of the vcpu whether >> the base address has been set and simply return an error if not. This >> latter approach just seems horrible and unintuitive to me. >> >> Thoughts? > > Wasn't there some "sane" field in the vcpu structs that you can hijack to make sure you only ever VCPU_RUN when the VM is complete? vcpu->requests is checked on each entry. -- error compiling committee.c: too many arguments to function