On 2/4/2019 2:43 PM, Borislav Petkov wrote:
On Mon, Feb 04, 2019 at 01:57:49PM -0500, Liang, Kan wrote:
You mean a given microcode revision X applying to multiple stepping,
right?
Yes, the range thing. You specify a range of steppings:
kabylake mobile with steppings 9-12
kabylake desktop
On Mon, Feb 04, 2019 at 01:57:49PM -0500, Liang, Kan wrote:
> You mean a given microcode revision X applying to multiple stepping,
> right?
Yes, the range thing. You specify a range of steppings:
kabylake mobile with steppings 9-12
kabylake desktop with steppings 10-13
> I don't think so. I
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"
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
On 2/4/2019 11:23 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+
On Mon, Feb 04, 2019 at 11:23:13AM -0500, Liang, Kan wrote:
> I mean that the microcode version number is irrelevant between stepping.
> Let's use SKL server as an example.
> + INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 3, 0x0021),
> + INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X,
On 2/4/2019 11:04 AM, Borislav Petkov wrote:
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
>
>
> On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
> > > +static const struct x86_cpu_desc isolation_ucodes[] = {
> > > + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
On 2/4/2019 11:15 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 10:43:41AM -0500, Liang, Kan wrote:
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1628,6 +1628,7 @@ void __init intel_ds_init(void)
x86_pmu.bts = boot_cpu_has(X86_FEATURE_BTS);
On 2/4/2019 11:10 AM, Peter Zijlstra wrote:
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
+ INTEL_CPU_DESC(INTEL_FAM6_CANNONLAKE_MOBILE, 3, 0x),
Funny that, CNL doesn't have any perf support at all yet.. Maybe do that
patch first or delay this
On Mon, Feb 04, 2019 at 10:43:41AM -0500, Liang, Kan wrote:
> > --- a/arch/x86/events/intel/ds.c
> > +++ b/arch/x86/events/intel/ds.c
> > @@ -1628,6 +1628,7 @@ void __init intel_ds_init(void)
> > x86_pmu.bts = boot_cpu_has(X86_FEATURE_BTS);
> > x86_pmu.pebs =
> As my understanding, the microcode version for each stepping is independent
> and irrelevant. The 0x004e should be just coincidence.
> If so, I don't think X86_STEPPING_ANY is very useful.
>
> Andi, if I'm wrong please correct me.
Yes that's right. You cannot match microcode without
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
> + INTEL_CPU_DESC(INTEL_FAM6_CANNONLAKE_MOBILE, 3, 0x),
Funny that, CNL doesn't have any perf support at all yet.. Maybe do that
patch first or delay this line to that patch?
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
>
>
> On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
> > > +static const struct x86_cpu_desc isolation_ucodes[] = {
> > > + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
On 2/4/2019 10:38 AM, Peter Zijlstra wrote:
This then? That's nearly what you had; except a lot less noisy.
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "../perf_event.h"
@@ -3206,16
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
> +static const struct x86_cpu_desc isolation_ucodes[] = {
> + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
> + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 10, 0x004e),
> +
On 2/4/2019 10:17 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:06:23PM +0100, Peter Zijlstra wrote:
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
So what's wrong with the below?
Installing a quirk for
(typing hard..)
but what I was going to say is
This then? That's nearly what you had; except a lot less noisy.
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "../perf_event.h"
@@ -3206,16 +3207,27 @@ static struct perf_guest_switch_msr *int
On Mon, Feb 04, 2019 at 04:06:23PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
>
> So what's wrong with the below?
>
> Installing a quirk for
(typing hard..)
but what I was going to say is that it seems overkill to sprinkle all
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
So what's wrong with the below?
Installing a quirk for
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3781,7 +3781,7 @@ static const struct x86_cpu_desc isolati
{}
};
-static void
From: Andi Kleen
KVM added a workaround for PEBS events leaking into guests with
commit 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the
PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates on
22 matches
Mail list logo
