From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses Date: Tue, 23 Oct 2012 12:48:28 +0200 Message-ID: <508675FC.7090901@siemens.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benjamin Herrenschmidt , Paul Mackerras , Alexander Graf , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kvm-ppc , Peter Maydell To: Christoffer Dall Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 2012-10-18 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? The current irqchip API is like this: KVM_CREATE_IRQCHIP (without any parameters) ... KVM_CREATE_VCPU KVM_SET_IRQCHIP (or the other way around) ... KVM_RUN The arguments you cannot pass via KVM_CREATE_IRQCHIP - which is more like a "Hey, there will be an IRQ chip!" - could be passed via KVM_SET_IRQCHIP (it has 512 bytes space). Provided there are sane configuration defaults, at least after KVM_CREATE_VCPU, KVM_SET_IRQCHIP becomes optional. Then you don't need the a check on KVM_RUN. What do we need in addition to this in any of the non-x86 archs? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux