kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, Tao Xu <tao3.xu@intel.com>,
	Xiaoyao Li <xiaoyao.li@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally
Date: Tue, 30 Jun 2020 16:41:49 +0300	[thread overview]
Message-ID: <08986e161635cc83d2d96b9729257dec91fc4562.camel@redhat.com> (raw)
In-Reply-To: <3642373d-8d1d-de80-d3db-e835a8f29449@redhat.com>

On Thu, 2020-05-21 at 10:40 +0200, Paolo Bonzini wrote:
> On 21/05/20 08:44, Tao Xu wrote:
> > I am sorry, I mean:
> > By default, we don't expose WAITPKG to guest. For QEMU, we can use
> > "-overcommit cpu-pm=on" to use WAITPKG.
> 
> But UMONITOR, UMWAIT and TPAUSE are not NOPs on older processors (which
> I should have checked before committing your patch, I admit).  So you
> have broken "-cpu host -overcommit cpu-pm=on" on any processor that
> doesn't have WAITPKG.  I'll send a patch.
> 
> Paolo
> 
Any update on that?

I accidently hit this today while updating my guest's kernel.
Turns out I had '-overcommit cpu-pm=on' enabled and -cpu host,
and waitpkg (which my AMD cpu doesn't have by any means) was silently
exposed to the guest but it didn't use it, but the mainline kernel started
using it and so it crashes.
Took me some time to realize that I am hitting this issue.


The CPUID_7_0_ECX_WAITPKG is indeed cleared in KVM_GET_SUPPORTED_CPUID,
and code in qemu sets/clears it depending on 'cpu-pm' value.

This patch (copy-pasted so probably not to apply) works for me regardless if we want to fix the KVM_GET_SUPPORTED_CPUID
returned value (which I think we should).
It basically detects the presence of the UMWAIT by presense of MSR_IA32_UMWAIT_CONTROL
in the global KVM_GET_MSR_INDEX_LIST, which I recently fixed too, to not return this
msr if the host CPUID doesn't support it.
So this works but is a bit ugly IMHO.

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 6adbff3d74..e9933d2e68 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -412,7 +412,7 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, uint32_t function,
             ret &= ~(CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_HLE);
         }
     } else if (function == 7 && index == 0 && reg == R_ECX) {
-        if (enable_cpu_pm) {
+        if (enable_cpu_pm && has_msr_umwait) {
             ret |= CPUID_7_0_ECX_WAITPKG;
         } else {
             ret &= ~CPUID_7_0_ECX_WAITPKG;
-- 

Should I send this patch officially?

Best regards,
	Maxim Levitsky



  reply	other threads:[~2020-06-30 13:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 16:07 [PATCH 0/2] Fix breakage from adding MSR_IA32_UMWAIT_CONTROL Maxim Levitsky
2020-05-20 16:07 ` [PATCH 1/2] kvm: cosmetic: remove wrong braces in kvm_init_msr_list switch Maxim Levitsky
2020-05-20 16:23   ` Vitaly Kuznetsov
2020-05-20 16:07 ` [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally Maxim Levitsky
2020-05-20 16:33   ` Vitaly Kuznetsov
2020-05-20 16:56     ` Maxim Levitsky
2020-05-20 17:15       ` Vitaly Kuznetsov
2020-05-20 17:39         ` Maxim Levitsky
2020-05-21  8:03       ` Xiaoyao Li
2020-05-20 21:05   ` Paolo Bonzini
2020-05-20 21:09     ` Maxim Levitsky
2020-05-21  4:33     ` Xiaoyao Li
2020-05-21  5:28       ` Tao Xu
2020-05-21  6:37         ` Xiaoyao Li
2020-05-21  6:44           ` Tao Xu
2020-05-21  8:40             ` Paolo Bonzini
2020-06-30 13:41               ` Maxim Levitsky [this message]
2020-05-21  8:24       ` Paolo Bonzini
2020-05-23 16:14 [PATCH 0/2] Fix issue with not starting nesting guests on my system Maxim Levitsky
2020-05-23 16:14 ` [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally Maxim Levitsky
2020-05-27  1:21   ` Sean Christopherson
2020-05-27 15:17     ` Maxim Levitsky

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=08986e161635cc83d2d96b9729257dec91fc4562.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=tao3.xu@intel.com \
    --cc=xiaoyao.li@intel.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;
as well as URLs for NNTP newsgroup(s).