From: Ingo Molnar <mingo@kernel.org>
To: Brendan Jackman <jackmanb@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] x86/cpu: Add facility to force-enable CPU caps and bugs
Date: Fri, 28 Feb 2025 11:07:19 +0100 [thread overview]
Message-ID: <Z8GK10q_ouii0O5F@gmail.com> (raw)
In-Reply-To: <CA+i-1C2dB94t7nDEd-41MgLeHMYGN2oQJyQE8qnkcx+xYdHfpA@mail.gmail.com>
* Brendan Jackman <jackmanb@google.com> 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
next prev parent reply other threads:[~2025-02-28 10:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 15:18 [PATCH v2 0/3] x86/cpu: Add facility to force-enable CPU caps and bugs Brendan Jackman
2024-12-20 15:18 ` [PATCH v2 1/3] x86/cpu: Create helper to parse clearcpuid param Brendan Jackman
2025-02-28 10:18 ` [tip: x86/cpu] x86/cpu: Create helper function to parse the 'clearcpuid=' boot parameter tip-bot2 for Brendan Jackman
2024-12-20 15:18 ` [PATCH v2 2/3] x86/cpu: Add setcpuid cmdline param Brendan Jackman
2025-02-28 10:18 ` [tip: x86/cpu] x86/cpu: Add the 'setcpuid=' boot parameter tip-bot2 for Brendan Jackman
2024-12-20 15:18 ` [PATCH v2 3/3] x86/cpu: Enable modifying bug flags with {clear,set}puid Brendan Jackman
2025-02-28 10:18 ` [tip: x86/cpu] x86/cpu: Enable modifying CPU bug flags with '{clear,set}puid=' tip-bot2 for Brendan Jackman
2025-01-13 15:42 ` [PATCH v2 0/3] x86/cpu: Add facility to force-enable CPU caps and bugs Brendan Jackman
2025-02-28 10:07 ` Ingo Molnar [this message]
2025-02-28 16:29 ` Ingo Molnar
2025-03-03 14:41 ` Brendan Jackman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8GK10q_ouii0O5F@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jackmanb@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.