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

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-12-08 12:46+0100, David Hildenbrand:
>> > 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.

Yes.  The admin would need that situation and disable incompatible
features in advance (KVM would just provide the option to do so).
The toggle would be a readonly kvm_module parameter, like we have for
ept and other features.

>> > 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.

Absurdly unlikely.  I hope it never happens with serious intentions.
(It is amusing to think about, but considering this situation is a waste
 of time for practical purposes.)

>> > (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?

Linux doesn't seem to do any sanity checks and it uses globals for CPUID
features and assumes that they are all the same, so we'd be getting what
we deserve.