On Thu, Jan 26, 2012 at 12:46:18PM +0200, Avi Kivity wrote: > 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. ok, I will try to handle CPU ejection without relying on the lifecycle patches. thanks, - Vasilis -- 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
