Re: [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Avi Kivity <avi@redhat.com>]

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