On Wed, Mar 14, 2012 at 10:42:50AM -0500, Anthony Liguori wrote:
> On 03/14/2012 10:35 AM, Gleb Natapov wrote:
> >On Wed, Mar 14, 2012 at 10:32:37AM -0500, Anthony Liguori wrote:
> >>On 03/14/2012 10:23 AM, Gleb Natapov wrote:
> >>>On Wed, Mar 14, 2012 at 02:49:59PM +0100, Vasilis Liaskovitis wrote:
> >>>>Hi,
> >>>>
> >>>>On Wed, Mar 14, 2012 at 09:37:18AM +0100, Igor Mammedov wrote:
> >>>>>On 03/14/2012 08:59 AM, Lai Jiangshan wrote:
> >>>>>>not accepted, so I don't know how to take part in.
> >>>>>
> >>>>>As I see it, there is not much to do from cpu hot-plug perspective.
> >>>>>It's just a matter of adaptation QOM-ified cpus for usage from
> >>>>>qdev device_add, and I'm working on it.
> >>>>>However, there is a lot to be done in cpu unplug area:
> >>>>> - host side: there is unaccepted patches to destroy vcpu
> >>>>> during VM-lifecycle. They are still need to be worked on:
> >>>>> "[Qemu-devel] [PATCH 0] A series patches for kvm&qemu to enable
> >>>>> vcpu destruction in kvm"
> >>>>> - linux guest side: kernel can receive ACPI request to unplug cpu,
> >>>>> but does nothing with it (last time I've tested it with 3.2 kernel),
> >>>>> You might wish to look at following mail threads:
> >>>>> https://lkml.org/lkml/2011/9/30/18
> >>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02254.html
> >>>>
> >>>>I also plan to resubmit the qemu-side of ACPI cpu unplug request:
> >>>>http://lists.nongnu.org/archive/html/qemu-devel/2012-01/msg03037.html
> >>>>so that they work independently of the "host side" patches mentioned
> >>>>above.
> >>>>
> >>>>It would be great for the QOMify/hotplug/icc patches to be accepted soon,
> >>>>since this would make unplug testing/development more straightoward.
> >>>>
> >>>On a different note, are your going to continue working on your memory hot
> >>>plug series?
> >>>I am going to look at it now.
> >>
> >>Memory hotplug.. that's going to be fun :-)
> >>
> >Why? What fundamental difficultly do you anticipate?
>
> There's still a few places in QEMU that assume that
> qemu_ram_get_ptr() returns a pointer that's good indefinitely.
>
> We also don't have a mechanism to revoke cpu_physical_map()
> pointers. Maybe the answer is reference counting and relying on
> being able to eventually release the memory... Of course, then an
> unplug followed by an immediate plug would be complicated.
>
Hmm, Avi assured me that with the memory API rework it should be easy :(
grep founds nothing about qemu_ram_get_ptr() and cpu_physical_map()
though. What should I look for?
> Hot add should be easy, hot remove will be pretty hard I think.
>
> Regards,
>
> Anthony Liguori
>
> >
> >--
> > Gleb.
--
Gleb.
