Re: [Qemu-devel] [PATCH v2 1/1] hyperv: cpu hotplug fix with HyperV enabled

["Denis V. Lunev" <den@openvz.org>]

On 02/17/2016 11:31 PM, Eduardo Habkost wrote:
> On Sat, Feb 13, 2016 at 03:00:15PM +0300, Denis V. Lunev wrote:
>> With Hyper-V enabled CPU hotplug stops working. The CPU appears in device
>> manager on Windows but does not appear in peformance monitor and control
>> panel.
>>
>> The root of the problem is the following. Windows checks
>> HV_X64_CPU_DYNAMIC_PARTITIONING_AVAILABLE bit in CPUID. The presence of
>> this bit is enough to cure the situation.
> What about live migration? This is going to change CPUID data
> under the guest's feet.
>
>> The bit should be set when CPU hotplug is allowed for HyperV VM. The check
>> that hot_add_cpu callback is defined is enough from the protocol point
>> of view. Though this callback is defined almost always thus there is no
>> need to export that knowledge in the other way.
> What would be the consequences of setting it when CPU hotplug is
> not available? Is there any real advantage of keeping it unset in
> pc-1.4 and older?
>
> If there are good reasons to keep it unset if CPU hotplug is not
> possible, why set it when max_cpus == smp_cpus?

I have made some tests with Win2k12 and the picture matches my
expectations. This property is read from CPUID once at system
boot:
- hotplug is working for VM with this property set after migration
   to QEMU which does not support this property
- hotplug remains not working after migration to QEMU which
   sets this property
No side effects detected but I have not checked that a lot.

I have discussed this thing with our local Windows experts and
they do not know side-effects of this.

Thus I think that we could set this unconditionally.

Any objections?