All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Fenghua Yu" <fenghua.yu@intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>, "H Peter Anvin" <hpa@zytor.com>,
	"Ravi V Shankar" <ravi.v.shankar@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [RFC PATCH 2/3] x86/cpufeatures: Combine word 11 and 12 into new scattered features word 11
Date: Fri, 14 Jun 2019 07:39:12 -0700	[thread overview]
Message-ID: <20190614143912.GB12191@linux.intel.com> (raw)
In-Reply-To: <20190614142139.GH2586@zn.tnic>

On Fri, Jun 14, 2019 at 04:21:39PM +0200, Borislav Petkov wrote:
> On Fri, Jun 14, 2019 at 07:14:24AM -0700, Sean Christopherson wrote:
> > This is wrong.  KVM isn't complaining about shuffling the order of feature
> > words, it's complaining that code is trying to do a reverse CPUID lookup
> > to a feature that isn't in the reverse_cpuid table.   Filtering out
> > checks dynamically is just hiding bugs.
> 
> No no, reverse_cpuid is hardcoding our feature leafs. This is wrong as
> we want to be able to change those. And reverse_cpuid[] should be able
> to handle that.
> 
> KVM is complaining because he removed one leaf. He adds it later in
> patch 3 as a Linux-defined leaf.

Yes, because removing that leaf breaks 'enum cpuid_leafs'.  Patch 3/3
"fixes" it by re-inserting a leaf, which causes 'enum cpuid_leafs' to
align with the CPU features.

For example, this assertion also fails:

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5b0e9d869ce5..c273b99702d0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -823,6 +823,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
                c->x86_capability[CPUID_7_0_EBX] = ebx;
                c->x86_capability[CPUID_7_ECX] = ecx;
                c->x86_capability[CPUID_7_EDX] = edx;
+               BUILD_BUG_ON(CPUID_7_EDX != X86_FEATURE_ARCH_CAPABILITIES/32);
        }
 
        /* Extended state features: level 0x0000000d */

In function ‘x86_feature_cpuid’,
    inlined from ‘guest_cpuid_get_register’ at arch/x86/kvm/cpuid.h:71:25,
    inlined from ‘guest_cpuid_has’ at arch/x86/kvm/cpuid.h:100:6,
    inlined from ‘kvm_get_msr_common’ at arch/x86/kvm/x86.c:2824:8:
include/linux/compiler.h:345:38: error: call to ‘__compiletime_assert_62’ declared with attribute error: BUILD_BUG_ON failed: x86_leaf >= ARRAY_SIZE(reverse_cpuid)
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)


But this assertion passes because its word is 10, i.e. below the 11/12
words that are getting mucked with.

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5b0e9d869ce5..aada9d2fa4df 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -830,6 +830,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
                cpuid_count(0x0000000d, 1, &eax, &ebx, &ecx, &edx);
 
                c->x86_capability[CPUID_D_1_EAX] = eax;
+               BUILD_BUG_ON(CPUID_D_1_EAX != X86_FEATURE_XSAVES/32);
        }
 
        /* AMD-defined flags: level 0x80000001 */


> All that doesn't matter for KVM - if KVM wants to do reverse lookup,
> then it should handle Linux-defined leafs just fine.

KVM can't handle Linux-defined leafs without extra tricks, which is why
I removed get_scattered_cpuid_leaf() or whatever it was called.

  reply	other threads:[~2019-06-14 14:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 20:51 [RFC PATCH 0/3] x86/cpufeatures: Re-arrange a few features and enumerate AVX512 BFLOAT16 intructions Fenghua Yu
2019-06-13 20:51 ` [RFC PATCH 1/3] x86/resctrl: Get max rmid and occupancy scale directly from CPUID instead of cpuinfo_x86 Fenghua Yu
2019-06-14 11:16   ` Borislav Petkov
2019-06-14 16:55     ` Fenghua Yu
2019-06-14 17:47       ` Borislav Petkov
2019-06-14 17:49         ` Fenghua Yu
2019-06-13 20:51 ` [RFC PATCH 2/3] x86/cpufeatures: Combine word 11 and 12 into new scattered features word 11 Fenghua Yu
2019-06-14 11:44   ` Borislav Petkov
2019-06-14 12:27     ` Borislav Petkov
2019-06-14 13:17       ` Fenghua Yu
2019-06-14 13:41         ` Borislav Petkov
2019-06-14 13:51           ` Fenghua Yu
2019-06-14 14:10             ` Borislav Petkov
2019-06-14 14:14           ` Sean Christopherson
2019-06-14 14:15             ` Fenghua Yu
2019-06-14 14:26               ` Borislav Petkov
2019-06-14 14:25                 ` Fenghua Yu
2019-06-14 15:02                   ` Borislav Petkov
2019-06-14 18:44                     ` Fenghua Yu
2019-06-14 14:21             ` Borislav Petkov
2019-06-14 14:39               ` Sean Christopherson [this message]
2019-06-14 14:57                 ` Borislav Petkov
2019-06-14 15:24                   ` Sean Christopherson
2019-06-14 16:10                     ` Borislav Petkov
2019-06-14 16:20                       ` Sean Christopherson
2019-06-13 20:51 ` [RFC PATCH 3/3] x86/cpufeatures: Enumerate new AVX512 BFLOAT16 instructions Fenghua Yu

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=20190614143912.GB12191@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=bp@alien8.de \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.