From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC PATCH 0/9] KVM: PPC: In-kernel PAPR interrupt controller emulation Date: Sat, 15 Dec 2012 13:06:13 +1100 Message-ID: <1355537173.19932.151.camel@pasglop> References: <20121105031806.GA22409@drongo> <8C03D615-A2C8-4126-8911-6088D1575E41@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Paul Mackerras , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org To: Alexander Graf Return-path: In-Reply-To: <8C03D615-A2C8-4126-8911-6088D1575E41@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote: > On 05.11.2012, at 04:18, Paul Mackerras wrote: > > > This series implements in-kernel emulation of the XICS interrupt > > controller specified in the PAPR specification and used by pseries > > guests. Since the XICS is organized a bit differently to the > > interrupt controllers used on x86 machines, I have defined some new > > ioctls for setting up the XICS and for saving and restoring its > > state. It may be possible to use some of the currently x86-specific > > ioctls instead. > > Is this one already following the new world order that we discussed during KVM Forum? :) The "new world order" .... (sorry, looks like nobody took notes and people expect me to do a write up from memory now ... :-) Well, mostly we agreed that the x86 stuff wasn't going to work for us. So basically what we discussed boils down to: - Move the existing "generic" KVM ioctl to create the kernel APIC to x86 since it's no as-is useful for other archs who, among other things, might need to pass argument based on the machine type (type of interrupt subsystem for example, etc...) - Once that's done, well, instanciating interrupt controller objects becomes pretty much an arch specific matter. We could try to keep some ioctls somewhat common though it's not *that* useful because the various types & arguments are going to be fairly arch specific, so goes for configuration. Examples of what could be kept common are: * Create irq chip, takes at least a "type" argument, possibly a few more type-specific args (or a union, but then let's keep space in there since we can't change the size of the struct later as it would impact the ioctl number afaik). * Assigning the address of an irq chip when it can change (see ARM patches) - The existing business with irqfd etc... is mostly ok, except the interfaces messing around with MSIs (see virtio-pci use of kvm functions directly). The assignment of an irq number for an MSI must be a hook, probably a PCI controller hook, so x86 can get it done via its existing kernel interfaces and sane architectures can keep the assignment in qemu where it belongs. Cheers, Ben.