From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: in-kernel interrupt controller steering Date: Wed, 6 Mar 2013 06:44:33 -0500 (EST) Message-ID: <1163682315.3171090.1362570273445.JavaMail.root@redhat.com> References: <20130306112629.GO11223@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Stuart Yoder , Scott Wood , Paul Mackerras , Peter Maydell To: Gleb Natapov Return-path: In-Reply-To: <20130306112629.GO11223@redhat.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org > > > So what is the difference between calling this special ioctl before > > > creating vcpus and calling create device ioctl instead and create > > > QEMU proxy device at whatever point in time QEMU wants to create > > > it? > > > > Because you'd have to stash the handle that KVM_CREATE_DEVICE > > returns somewhere, waiting for the QEMU device to be created. > > OK, we try not to add interfaces for one userspace convenience > though. Is this such insurmountable problem for QEMU? Nothing is insurmountable. However, forcing a particular order of device creation is not very nice on userspace. If the hypervisor wants to do that, it can do userspace the favor of keeping the id in kernel. :) > > Perhaps it's just a problem of naming, and KVM_CREATE_DEVICE is simply > > not the right name for the interface. Once both KVM_CREATE_IRQCHIP_ARGS > > and KVM_CREATE_DEVICE are added, it really will not create the > > device anymore. > > Devices will be created by KVM_CREATE_IRQCHIP_ARGS, and possibly by > > KVM_CREATE_VCPU. KVM_CREATE_DEVICE is really only returning an id. > > > > So we can have this instead: > > - KVM_CREATE_IRQCHIP_ARGS becomes KVM_SET_IRQCHIP_TYPE (and "none" > > can be a valid irqchip type). > > > > - KVM_CREATE_DEVICE becomes KVM_GET_IRQCHIP_DEVICE, and you pass it > > a device type and possibly a VCPU number. > > > > It's mostly about names, but one important property is that > > KVM_GET_IRQCHIP_DEVICE can be called at any time and, in fact, > > multiple times. Gleb, do you like this more? > > If you put it like this it sounds better (well you've just stashed > the handle in kernel for QEMU convenience :)), but you've made the > interface irqchips specific again and this is what we are trying to avoid. Yes, KVM_GET_IRQCHIP_DEVICE is specific to irqchips because (following the model of x86) the irqchip type is chosen before creating VCPUs. I don't see an alternative unless we stop having irqchip as an all-or-nothing choice. I'm not saying KVM_CREATE_DEVICE is a bad interface, but I'm not sure it is really what is needed in this case. KVM_CREATE_DEVICE would be perfect as a replacement for KVM_CREATE_PIT2, for example. But in this case creating a device is not what we're really doing; the creation is done magically by the hypervisor by virtue of the previous KVM_CREATE_IRQCHIP_ARGS. Paolo