Re: PATCH: setup_vmcs_config: disable TSC scaling on unlike processors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




My intuition tells me that whenever we hotplug CPUs that have less features
than used, we are in trouble. So tsc scaling might just be the tip of the
iceberg. I think this is a general problem.

Definitely.  It was not handled in KVM probably because it doesn't have
a simple solution.

Finding the minimal common subset on hotplug will take extra work, which
is why relaxing the check and having a toggle for features that
shouldn't be enabled nor checked is easier.

But even with a toggle, the problem of not knowing what will be hotplugged persists. Before hotplugging, the admin would have to restart all guests after flipping the toggle.


What should happen if we hotplug such CPUs? We can't run existing VCPUs on
them. And isn't this even a general problem, also for other tasks in the
system (how is that problem solved with cpuid features?)?

1) Prevent the hotplug -- admin can notice the error, kill guests or
   decide to let them finish, and then online hotplugged CPU.

2) Just warn and trust that admin knows what hotplugging to non-SMP
   means.

(2) is less work and give a bit more freedom to an undesirable case, so
I slightly prefer it.  I wouldn't for example limit existing VCPUs to
compatible CPUs or cleanly kill all guests from the kernel.

And I assume that such scenarios are also quite unlikely. Or is it a common practice in production to hotplug random CPUs from the shelf? I doubt it.


(I am currently thinking about "virsh capabilities", could it happen that
our "host" cpu model is no longer valid after we hotplugged cpus (as the
common feature set got smaller)? that would be very ugly)

I think it could, but I'd continue in thinking only about SMP.  VMX
features are not even noticed by `virsh capabilities`, so finding the
minimal common subset in KVM would not affect the output.

Do you know if we can hotplug CPUs with differing CPUID features on x86?

--

David
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux