Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Hot add should be easy, hot remove will be pretty hard I think.

Regards,

Anthony Liguori

>
> --
> 			Gleb.