[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/1] hyperv: cpu hotplug fix with HyperV enab
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/1] hyperv: cpu hotplug fix with HyperV enabled |
Date: |
Thu, 18 Feb 2016 15:47:43 -0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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