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

From: "Radim Krčmář" <rkrcmar@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Don Bowman <db@donbowman.ca>,
	kvm@vger.kernel.org
Subject: Re: PATCH: setup_vmcs_config: disable TSC scaling on unlike processors
Date: Wed, 7 Dec 2016 16:25:21 +0100	[thread overview]
Message-ID: <20161207152520.GA15611@potion> (raw)
In-Reply-To: <22b615ad-9161-2fef-4d17-885c33b0ac76@redhat.com>

2016-12-07 12:37+0100, David Hildenbrand:
>> Yes, that is reasonable -- I though David wanted to use the feature when
>> running on CPUs that support it (only mask off on the one).
>> 
>> I'd start with changing the check in vmx_check_processor_compat() to
>> ignore disabled features and then extend KVM to enable only the common
>> set.
>> 
>> Finding the minimal set of common features is complicated by hotplug ...
>> I think that the check we have is not working perfectly, so if you
>> currently
>> 
>>  1) offline all cores on the worse CPU
>>  2) load kvm module
>>  3) online all CPUs
>> 
>> then KVM is going enable tsc-scaling and not complain, but guests
>> running on onlined CPUs are not going to work.
>> Can you confirm that?
> 
> 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.

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

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