Re: [PATCH v2 0/3] x86/cpu: Add facility to force-enable CPU caps and bugs

[Brendan Jackman]

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!