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.
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
-
Avi Kivity -
Vasilis Liaskovitis