From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWRnS-0001l3-9r for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:51:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWRnO-0007KG-22 for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:51:18 -0500 Received: from mx2.parallels.com ([199.115.105.18]:34055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWRnN-0007G0-Sw for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:51:13 -0500 References: <1455364815-19586-1-git-send-email-den@openvz.org> <20160217203105.GA14502@thinpad.lan.raisama.net> From: "Denis V. Lunev" Message-ID: <56C5F673.5040701@openvz.org> Date: Thu, 18 Feb 2016 19:50:59 +0300 MIME-Version: 1.0 In-Reply-To: <20160217203105.GA14502@thinpad.lan.raisama.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/1] hyperv: cpu hotplug fix with HyperV enabled List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Paolo Bonzini , Richard Henderson , qemu-devel@nongnu.org, =?UTF-8?Q?Andreas_F=c3=a4rber?= 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?