From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: PATCH: setup_vmcs_config: disable TSC scaling on unlike processors Date: Wed, 7 Dec 2016 16:25:21 +0100 Message-ID: <20161207152520.GA15611@potion> References: <20161202150632.GA22204@potion> <59a3f1a2-5b9e-2ca7-5285-1469fef40f42@redhat.com> <20161206110858.GC8660@potion> <22b615ad-9161-2fef-4d17-885c33b0ac76@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Paolo Bonzini , Don Bowman , kvm@vger.kernel.org To: David Hildenbrand Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35482 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932311AbcLGPZY (ORCPT ); Wed, 7 Dec 2016 10:25:24 -0500 Content-Disposition: inline In-Reply-To: <22b615ad-9161-2fef-4d17-885c33b0ac76@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.