> > >>>> 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. > > > > No, it's not and it shouldn't be. To speak in x86 terms: > > > > KVM_SET_IRQCHIP_TYPE spawns LAPICs (indirectly, they only get > > spawned on vcpu creation) > > KVM_CREATE_DEVICE spawns IOAPICs.
Ok, that makes sense. > Agree. Lumping up in-kernel LAPIC and IRQCHIPS under one in-kernel > irqchip umbrella was a mistake on x86. The one we should not force on > others. Alex, would the PPC patches let you run with in-kernel "LAPICs" and userspace "IOAPICs"? If so, the new model would not be a problem with QEMU at all. The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
