On Fri, Feb 28, 2025 at 05:29:45PM +0100, Ingo Molnar wrote: > * Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > Integration with clearcpuid= is so much more generic than the original > > variant and reuses a lot of that logic, so that's a big plus. > > > > I've applied it to the x86 tree under the tip:x86/cpu branch and if > > everything goes fine in testing it should hit v6.15 in a couple of > > weeks. It seems you applied this version (v2) while there was actually a review from Boris on this and it led to v3: https://lore.kernel.org/linux-kernel/20250218-force-cpu-bug-v3-0-da3df43d1936@xxxxxxxxxx/ This is weird, I can't see Boris' comments on Lore, even though they are Cc'd to linux-kernel@xxxxxxxxxxxxxxx. I think there was some downtime on Lore recently, maybe they got lost? > > One additional thing - which I'd suggest we make a 4th patch, because > > it affects the existing clearcpuid= behavior - is to extend > > set/clearcpuid= with a bit more boot time verbosity, right now it > > taints the kernel: > > > > /* empty-string, i.e., ""-defined feature flags */ > > if (!x86_cap_flags[bit]) > > pr_cont(" " X86_CAP_FMT_NUM, x86_cap_flag_num(bit)); > > else > > pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit)); > > > > if (set) > > setup_force_cpu_cap(bit); > > else > > setup_clear_cpu_cap(bit); > > taint++; > > > > > > I'd suggest we do what PeterZ suggested back in December: in addition > > to the tainting, also emit an informative pr_warn() for every CPU > > feature bit enabled/disabled over what was present, and maybe make a > > bit of a distinction between 'feature' and 'bug' feature bits. > > Ie. what I mean is that at minimum upgrade the output from pr_info() to > pr_warn() - but maybe also make it clear in the output that the kernel > is tainted and things may break as a result of modifying the feature > bits. Anyway, yep, I will send some upgrades to the logging, plus any diff that got lost from v2 to v3 as a new series. Thanks for taking a look!
