| Message ID | 1455364815-19586-1-git-send-email-den@openvz.org |
|---|---|
| State | New |
| Headers | show |
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
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 > >
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?
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.
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; }