All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.