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

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

[Denis V. Lunev]

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.

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.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Eduardo Habkost <ehabkost@redhat.com>
CC: "Andreas Färber" <afaerber@suse.de>
---
Changes from v1:
- dropped command line option and set the bit if HyperV is enabled and
  hot_add_cpu callback is present

 target-i386/kvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 94024bc..63dee9c 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -639,6 +639,9 @@ int kvm_arch_init_vcpu(CPUState *cs)
         if (cpu->hyperv_crash && has_msr_hv_crash) {
             c->edx |= HV_X64_GUEST_CRASH_MSR_AVAILABLE;
         }
+        if (MACHINE_GET_CLASS(current_machine)->hot_add_cpu != NULL) {
+            c->edx |= HV_X64_CPU_DYNAMIC_PARTITIONING_AVAILABLE;
+        }
         if (cpu->hyperv_reset && has_msr_hv_reset) {
             c->eax |= HV_X64_MSR_RESET_AVAILABLE;
         }
-- 
2.5.0

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

[Denis V. Lunev]

On 02/13/2016 03:00 PM, 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.
>
> 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.
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Richard Henderson <rth@twiddle.net>
> CC: Eduardo Habkost <ehabkost@redhat.com>
> CC: "Andreas Färber" <afaerber@suse.de>
> ---
> Changes from v1:
> - dropped command line option and set the bit if HyperV is enabled and
>    hot_add_cpu callback is present
>
>   target-i386/kvm.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 94024bc..63dee9c 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -639,6 +639,9 @@ int kvm_arch_init_vcpu(CPUState *cs)
>           if (cpu->hyperv_crash && has_msr_hv_crash) {
>               c->edx |= HV_X64_GUEST_CRASH_MSR_AVAILABLE;
>           }
> +        if (MACHINE_GET_CLASS(current_machine)->hot_add_cpu != NULL) {
> +            c->edx |= HV_X64_CPU_DYNAMIC_PARTITIONING_AVAILABLE;
> +        }
>           if (cpu->hyperv_reset && has_msr_hv_reset) {
>               c->eax |= HV_X64_MSR_RESET_AVAILABLE;
>           }
ping

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

[Eduardo Habkost]

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?


> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Richard Henderson <rth@twiddle.net>
> CC: Eduardo Habkost <ehabkost@redhat.com>
> CC: "Andreas Färber" <afaerber@suse.de>
> ---
> Changes from v1:
> - dropped command line option and set the bit if HyperV is enabled and
>   hot_add_cpu callback is present
> 
>  target-i386/kvm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 94024bc..63dee9c 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -639,6 +639,9 @@ int kvm_arch_init_vcpu(CPUState *cs)
>          if (cpu->hyperv_crash && has_msr_hv_crash) {
>              c->edx |= HV_X64_GUEST_CRASH_MSR_AVAILABLE;
>          }
> +        if (MACHINE_GET_CLASS(current_machine)->hot_add_cpu != NULL) {
> +            c->edx |= HV_X64_CPU_DYNAMIC_PARTITIONING_AVAILABLE;
> +        }
>          if (cpu->hyperv_reset && has_msr_hv_reset) {
>              c->eax |= HV_X64_MSR_RESET_AVAILABLE;
>          }
> -- 
> 2.5.0
> 
> 

-- 
Eduardo

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

[Denis V. Lunev]

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?

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