From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, ak@linux.intel.com, eranian@google.com
Subject: Re: [PATCH V6 2/5] perf/x86/kvm: Avoid unnecessary work in guest filtering
Date: Mon, 4 Feb 2019 13:57:49 -0500 [thread overview]
Message-ID: <134894ac-a43b-7ec7-f313-b5d8de357a7e@linux.intel.com> (raw)
In-Reply-To: <20190204181504.GH29639@zn.tnic>
On 2/4/2019 1:15 PM, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 11:55:27AM -0500, Liang, Kan wrote:
>
>> We cannot apply X86_STEPPING_ANY to ignore the stepping. There will be
>> problems for 0-8 stepping for KABYLAKE_MOBILE.
>
> So why are we even doing this new "interface"
> x86_cpu_has_min_microcode_rev() if even at the conversion stage it shows
> that it is inadequate?
>
>> I think what we need is x86_match_cpu_with_stepping_range().
>> But I don't think it is worth enabling it just for this rare case.
>
> Sounds to me like you wanna go back to the drawing board after having
> evaluated all the use cases.
>
> And yes, I can imagine:
>
> +struct x86_cpu_desc {
> + __u8 x86; /* CPU family */
> + __u8 x86_vendor; /* CPU vendor */
> + __u8 x86_model;
> + __u8 x86_min_stepping;
> + __u8 x86_max_stepping;
> + __u32 x86_microcode_rev;
> +};
>
> along with the usage:
>
> INTEL_CPU_DESC(mod, min_step, max_step, rev)
>
> to make it more elegant.
>
> Question is, can you have a given microcode revision X applying to
> multiple revisions?
>
> If yes, the above should work...
>
You mean a given microcode revision X applying to multiple stepping,
right?
I don't think so. I still think the KABYLAKE case is an uncommon case.
Can we do something as below just for this case?
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 3eacdf6..d5fba67 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3745,6 +3745,12 @@ static __init void intel_clovertown_quirk(void)
x86_pmu.pebs_constraints = NULL;
}
+#define INTEL_CPU_DESC_FOUR(mod, start, rev) \
+ INTEL_CPU_DESC(mod, start, rev), \
+ INTEL_CPU_DESC(mod, start + 1, rev), \
+ INTEL_CPU_DESC(mod, start + 2, rev), \
+ INTEL_CPU_DESC(mod, start + 3, rev)
+
static const struct x86_cpu_desc isolation_ucodes[] = {
INTEL_CPU_DESC(INTEL_FAM6_HASWELL_CORE, 3, 0x0000001f),
INTEL_CPU_DESC(INTEL_FAM6_HASWELL_ULT, 1, 0x0000001e),
@@ -3763,15 +3769,8 @@ static const struct x86_cpu_desc
isolation_ucodes[] = {
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_MOBILE, 3, 0x0000007c),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_DESKTOP, 3, 0x0000007c),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 9, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 10, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 11, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 12, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 10, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 11, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 12, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 13, 0x0000004e),
- INTEL_CPU_DESC(INTEL_FAM6_CANNONLAKE_MOBILE, 3, 0x00000000),
+ INTEL_CPU_DESC_FOUR(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x0000004e),
+ INTEL_CPU_DESC_FOUR(INTEL_FAM6_KABYLAKE_DESKTOP,10, 0x0000004e),
{}
};
Thanks,
Kan
next prev parent reply other threads:[~2019-02-04 18:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 21:42 [PATCH V6 1/5] x86/cpufeature: Add facility to check for min microcode revisions kan.liang
2019-01-21 21:42 ` [PATCH V6 2/5] perf/x86/kvm: Avoid unnecessary work in guest filtering kan.liang
2019-02-04 15:06 ` Peter Zijlstra
2019-02-04 15:17 ` Peter Zijlstra
2019-02-04 15:39 ` Liang, Kan
2019-02-04 15:38 ` Peter Zijlstra
2019-02-04 15:43 ` Liang, Kan
2019-02-04 16:15 ` Peter Zijlstra
2019-02-04 16:18 ` Liang, Kan
2019-02-04 15:44 ` Peter Zijlstra
2019-02-04 15:57 ` Liang, Kan
2019-02-04 16:04 ` Borislav Petkov
2019-02-04 16:23 ` Liang, Kan
2019-02-04 16:41 ` Borislav Petkov
2019-02-04 16:13 ` Andi Kleen
2019-02-04 16:23 ` Peter Zijlstra
2019-02-04 16:55 ` Liang, Kan
2019-02-04 18:15 ` Borislav Petkov
2019-02-04 18:57 ` Liang, Kan [this message]
2019-02-04 19:43 ` Borislav Petkov
2019-02-04 20:37 ` Liang, Kan
2019-02-04 16:10 ` Peter Zijlstra
2019-02-04 16:16 ` Liang, Kan
2019-01-21 21:42 ` [PATCH V6 3/5] perf/x86/intel: Clean up SNB pebs quirk kan.liang
2019-01-21 21:42 ` [PATCH V6 4/5] perf/x86/intel: Clean up counter freezing quirk kan.liang
2019-01-21 21:42 ` [PATCH V6 5/5] perf/x86/intel: Add counter freezing quirk for Goldmont kan.liang
2019-02-04 14:27 ` [PATCH V6 1/5] x86/cpufeature: Add facility to check for min microcode revisions Liang, Kan
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=134894ac-a43b-7ec7-f313-b5d8de357a7e@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®