On 01/24/2012 04:56 PM, Vasilis Liaskovitis wrote: > On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote: > > On 2012-01-24 11:10, Vasilis Liaskovitis wrote: > > > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and > > > enable eject callback only for pc-1.1 machine model. > > > > Just to get the idea: What is the plan and advantage of introducing a > > stub first? How much more is required to have some usable feature, even > > if its just a friction of the full support? > > > There's not really an advantage to adding stubs first. The plan depends on the > lifecycle patches getting accepted in some form at some point. The code is all > out there, and some of it has been reviewed/commented on, but not accepted. > > kvm needs the following patches: > https://lkml.org/lkml/2012/1/6/355 (v7, still in work) > http://patchwork.ozlabs.org/patch/127828/ > This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal > vcpu destruction to the host) but the review mentions there should be a > simpler way. It's unclear to me whether this ioctl is desired or not. Those patches are not strictly needed. On a kernel that doesn't have them, you can simply park the vcpu thread in userspace until it is re-added. I suggest writing the qemu patches without the assumption that you're running on a 3.4+ kernel. -- error compiling committee.c: too many arguments to function -- 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
