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.
next prev parent reply other threads:[~2016-12-07 15:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-02 2:32 PATCH: setup_vmcs_config: disable TSC scaling on unlike processors Don Bowman
2016-12-02 15:07 ` Radim Krčmář
2016-12-02 19:10 ` Don Bowman
2016-12-02 20:58 ` Don Bowman
2016-12-05 16:37 ` Radim Krčmář
2016-12-06 8:49 ` David Hildenbrand
2016-12-06 9:09 ` Paolo Bonzini
2016-12-06 11:08 ` Radim Krčmář
2016-12-07 11:37 ` David Hildenbrand
2016-12-07 15:25 ` Radim Krčmář [this message]
2016-12-08 11:46 ` David Hildenbrand
2016-12-08 14:32 ` Radim Krčmář
2016-12-09 15:12 ` Don Bowman
2016-12-13 15:43 ` Radim Krčmář
2016-12-14 4:07 ` Don Bowman
2016-12-14 12:30 ` Paolo Bonzini
2016-12-14 12:46 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161207152520.GA15611@potion \
--to=rkrcmar@redhat.com \
--cc=david@redhat.com \
--cc=db@donbowman.ca \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox