* Brendan Jackman <jackmanb@xxxxxxxxxx> wrote:
> Hi folks, happy new year. I hope this ping isn't too aggressive given
> the season - please let me know if it is.
>
> Any new thoughts on this?
Sorry, this series got lost in the holiday season (apparently you
weren't nearly pushy enough to breach the maintainer patch-detection
noise/signal level :-), and this functionality is definitely useful and
the series looks good to me.
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.
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.
Thanks,
Ingo
