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

[Eduardo Habkost]

On Thu, Feb 18, 2016 at 07:50:59PM +0300, Denis V. Lunev wrote:
> 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.
> 

We avoid changing CPUID of a running VM, but if HyperV experts
don't see any issues I won't mind keeping it simple.

-- 
Eduardo