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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
