From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUEvw-0001kU-3W for qemu-devel@nongnu.org; Fri, 12 Feb 2016 09:42:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUEvs-0003mU-P4 for qemu-devel@nongnu.org; Fri, 12 Feb 2016 09:42:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUEvs-0003mM-Hk for qemu-devel@nongnu.org; Fri, 12 Feb 2016 09:42:52 -0500 Date: Fri, 12 Feb 2016 15:42:48 +0100 From: Igor Mammedov Message-ID: <20160212154248.1ce49144@nial.brq.redhat.com> In-Reply-To: <56BDC19D.6060203@openvz.org> References: <1455221959-22728-1-git-send-email-den@openvz.org> <56BDBB31.3010302@suse.de> <56BDBD24.5040700@openvz.org> <56BDBE76.7070005@suse.de> <56BDC19D.6060203@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/1] hyperv: cpu hotplug fix with HyperV enabled List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Eduardo Habkost , qemu-devel@nongnu.org, "Alexey V. Kostyushko" , Paolo Bonzini , Andreas =?UTF-8?B?RsOkcmJlcg==?= , Richard Henderson On Fri, 12 Feb 2016 14:27:25 +0300 "Denis V. Lunev" wrote: > On 02/12/2016 02:13 PM, Andreas F=C3=A4rber wrote: > > Am 12.02.2016 um 12:08 schrieb Denis V. Lunev: =20 > >> On 02/12/2016 02:00 PM, Andreas F=C3=A4rber wrote: =20 > >>> Am 11.02.2016 um 21:19 schrieb Denis V. Lunev: =20 > >>>> From: "Alexey V. Kostyushko" > >>>> > >>>> With Hyper-V enabled CPU hotplug stops working. The CPU appears in > >>>> device > >>>> manager on Windows but does not appear in peformance monitor and con= trol > >>>> 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. > >>>> > >>>> Add option 'hv-cpuhotplug' to control this behavior. > >>>> > >>>> Signed-off-by: Alexey V. Kostyushko > >>>> Signed-off-by: Denis V. Lunev > >>>> CC: Paolo Bonzini > >>>> CC: Richard Henderson > >>>> CC: Eduardo Habkost > >>>> CC: "Andreas F=C3=A4rber" > >>>> --- > >>>> target-i386/cpu-qom.h | 1 + > >>>> target-i386/cpu.c | 1 + > >>>> target-i386/kvm.c | 6 +++++- > >>>> 3 files changed, 7 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h > >>>> index 5f9d960..4aec616 100644 > >>>> --- a/target-i386/cpu-qom.h > >>>> +++ b/target-i386/cpu-qom.h > >>>> @@ -96,6 +96,7 @@ typedef struct X86CPU { > >>>> bool hyperv_runtime; > >>>> bool hyperv_synic; > >>>> bool hyperv_stimer; > >>>> + bool hyperv_cpuhotplug; > >>>> bool check_cpuid; > >>>> bool enforce_cpuid; > >>>> bool expose_kvm; > >>>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c > >>>> index b255644..32c38ae 100644 > >>>> --- a/target-i386/cpu.c > >>>> +++ b/target-i386/cpu.c > >>>> @@ -3172,6 +3172,7 @@ static Property x86_cpu_properties[] =3D { > >>>> DEFINE_PROP_BOOL("hv-runtime", X86CPU, hyperv_runtime, false), > >>>> DEFINE_PROP_BOOL("hv-synic", X86CPU, hyperv_synic, false), > >>>> DEFINE_PROP_BOOL("hv-stimer", X86CPU, hyperv_stimer, false), > >>>> + DEFINE_PROP_BOOL("hv-cpuhotplug", X86CPU, hyperv_cpuhotplug, > >>>> false), =20 > >>> Is "cpuhotplug" some fixed HyperV name? Otherwise we generally use a > >>> dashes convention for QOM properties, i.e. "hv-cpu-hotplug". > >>> > >>> Regards, > >>> Andreas =20 > >> This name is for libvirt. We can take one one. This is not a problem. > >> > >> Roman Kagan has proposed verbally a bit different approach. > >> He suggests not to introduce the option but > >> check here that HyperV is enabled (any single option is enough > >> to face the problem) and CPU hotplug is enabled and automatically > >> enable this bit. > >> > >> Paolo, Andreas, is there any opinion on this? =20 > > That implicit proposal sounds even more appealing to me, yes. > > > > You could still additionally do a dynamic property though, in case you > > want to inspect or toggle it at runtime (no clue when Windows reads it)= . =20 > no. this will not work. I should setup CPUID at the beginning > (before boot) and keep it persistent. Thus either option > coming from libvirt or this bit would be automatically > calculated by QEMU. >=20 > I'll check that we could create read-only property to export > the value. >=20 > OK. I'll redo this tomorrow if nobody will explicitly say 'no' > today :) +to Anreas suggestion and readonly prop there is not need to create a field for it in CPU structure, just checking for present hyperv flags should be sufficient. >=20 > Den >=20