[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for ac
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4 |
Date: |
Thu, 26 Jan 2012 12:46:18 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
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
[Qemu-devel] [PATCH 4/4] uq/master: Add acpi cpu interface documentation, Vasilis Liaskovitis, 2012/01/24
[Qemu-devel] [PATCH v2 1/4][SeaBios] Add bitmap for CPU EJ0 callback, Vasilis Liaskovitis, 2012/01/24