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?
