[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240416174850.GEZh66AmnDjrLxoXaw@fat_crate.local>
Date: Tue, 16 Apr 2024 19:48:50 +0200
From: Borislav Petkov <bp@...en8.de>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Robert Richter <rric@...nel.org>, linux-kernel@...r.kernel.org,
jgross@...e.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: [PATCH 2/4] perf/x86/ibs: Use CPUID region helper
On Tue, Apr 16, 2024 at 08:23:58AM -0700, Dave Hansen wrote:
> When I was looking at it, I (maybe wrongly) assumed that 0x8000001b and
> X86_FEATURE_IBS were independent for a reason. Because, oddly enough:
>
> #define IBS_CAPS_DEFAULT (IBS_CAPS_AVAIL \
> | IBS_CAPS_FETCHSAM \
> | IBS_CAPS_OPSAM)
>
> So, if the CPU enumerates X86_FEATURE_IBS but has a
> max_level<IBS_CPUID_FEATURES then it assumes there's a working IBS
> because the software-inserted IBS_CAPS_DEFAULT has IBS_CAPS_AVAIL set.
Right, that's why I added Robert. I found this in a F10h doc (old
Greyhound CPU rust):
"CPUID Fn8000_0001_ECX Feature Identifiers
..
10: IBS: Instruction Based Sampling = 1.
..
CPUID Fn8000_001B Instruction Based Sampling Identifiers
..
IBSFFV. IBS feature flags valid. Revision B = 0. Revision C = 1."
which makes this look like some hack to fix broken CPUID IBS reporting.
And if it is that, I don't think we care, frankly, because revB is
ooold. Mine is somewhere in the basement on some old board which got
bricked so I don't know even if I could use it anymore.
And I'm not even planing to - that CPU is almost 20 years old and no one
cares whether it can even do IBS.
So I wouldn't mind at all if we simplify this code for the sake of it.
I don't think anyone would care or notice.
But let's see what Robert says first...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists