mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Chang S. Bae" <chang.seok.bae@intel.com>, linux-kernel@vger.kernel.org
Cc: x86@kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, hpa@zytor.com,
	andrew.cooper3@citrix.com, arjan.van.de.ven@intel.com,
	sohil.mehta@intel.com, stable@vger.kernel.org
Subject: Re: [PATCH v2] x86/microcode/intel: Reject problematic loading on Granite Rapids systems
Date: Tue, 8 Sep 2026 16:16:15 -0700	[thread overview]
Message-ID: <0bfbb372-31cc-42af-b485-001f9a64f3b5@intel.com> (raw)
In-Reply-To: <20260908223209.916758-1-chang.seok.bae@intel.com>

On 9/8/26 15:32, Chang S. Bae wrote:
> Microcode updates can usually jump revisions. However, there is an
> erratum on Granite Rapids systems. If they "jump over" to revision
> 0x1000405 or later, they result in #MC.
> 
> Prevent loading 0x1000405 or later unless the running revision is already
> at least 0x1000405. Apply this blocking to both early- and late-loading
> paths.

This is a kinda wonky-looking patch but I don't know a nicer way to do
it, so:

Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>

> +static bool revision_banned(struct cpu_signature *sig, u32 rev)
> +{
> +	u32 vfm = IFM(x86_family(sig->sig), x86_model(sig->sig));
> +
> +	/*
> +	 * Revision 0x1000405 contains prerequisite changes for subsequent
> +	 * microcode updates on Granite Rapids systems. Updates directly from
> +	 * an older revision to this or a newer one can result in #MC. This is
> +	 * documented item GNR98, #835486 (Intel Xeon 6900/6700/6500-Series
> +	 * Processors with P-Cores).
> +	 */

I honestly still prefer that this comment be more short and sweet. Does
this miss anything?

	/*
	 * Erratum GNR98 can cause #MC's if "jumping over"
	 * revision 0x1000405. Avoid the jumps.
	 */

Also, we don't need to put whole document titles or numbers in here.
They're fine, but if you can Google "erratum GNR98" and get the doc for
the first hit, what does it matter?

Leave the precision and long chit chat for the changelog, I say.

But we can edit this in place when it gets applied.

> +	if (vfm == INTEL_GRANITERAPIDS_X &&
> +	    x86_stepping(sig->sig) == 1 &&
> +	    sig->pf & 0x95 &&
> +	    sig->rev < 0x1000405 &&
> +	    rev >= 0x1000405) {
> +		if (rev == 0x1000405)
> +			pr_err_once("Erratum GNR98: revision 0x1000405 is not loadable.\n");
> +		else
> +			pr_err_once("Erratum GNR98: revision 0x1000405 is required before 0x%x.\n", rev);
> +		return true;
> +	}
> +
> +	return false;
> +}
> +
>  /* Scan blob for microcode matching the boot CPUs family, model, stepping */
>  static __init struct microcode_intel *scan_microcode(void *data, size_t size,
>  						     struct ucode_cpu_info *uci,
> @@ -330,6 +356,9 @@ static __init struct microcode_intel *scan_microcode(void *data, size_t size,
>  		if (!intel_find_matching_signature(data, &uci->cpu_sig))
>  			continue;
>  
> +		if (revision_banned(&uci->cpu_sig, mc_header->rev))
> +			continue;
> +
>  		/*
>  		 * For saving the early microcode, find the matching revision which
>  		 * was loaded on the BSP.
> @@ -878,6 +907,9 @@ static enum ucode_state parse_microcode_blobs(int cpu, struct iov_iter *iter)
>  		if (!intel_find_matching_signature(mc, &uci->cpu_sig))
>  			continue;
>  
> +		if (revision_banned(&uci->cpu_sig, mc_header.rev))
> +			continue;
> +
>  		is_safe = ucode_validate_minrev(&mc_header);
>  		if (force_minrev && !is_safe)
>  			continue;


  reply	other threads:[~2026-09-08 23:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 23:16 [PATCH 0/8] x86/microcode: Address GNR errata and follow-up Chang S. Bae
2026-09-01 23:16 ` [PATCH 1/8] x86/microcode/intel: Reject problematic loading on GNR systems Chang S. Bae
2026-09-02 13:11   ` Sohil Mehta
2026-09-02 13:21     ` Van De Ven, Arjan
2026-09-08 23:03     ` Chang S. Bae
2026-09-02 14:23   ` Dave Hansen
2026-09-03  1:51   ` Borislav Petkov
2026-09-03 21:04     ` Chang S. Bae
2026-09-08 22:32   ` [PATCH v2] x86/microcode/intel: Reject problematic loading on Granite Rapids systems Chang S. Bae
2026-09-08 23:16     ` Dave Hansen [this message]
2026-09-09  0:13     ` Borislav Petkov
2026-09-09  0:39       ` Chang S. Bae
2026-09-09  0:14     ` Andrew Cooper
2026-09-01 23:16 ` [PATCH 2/8] x86/microcode: Solidify base_rev= option parsing Chang S. Bae
2026-09-01 23:16 ` [PATCH 3/8] x86/microcode: Accept a boolean for force_minrev parameter Chang S. Bae
2026-09-01 23:16 ` [PATCH 4/8] x86/microcode: Mark early_data __initdata Chang S. Bae
2026-09-01 23:16 ` [PATCH RFC 5/8] x86/microcode: Decouple minimum revision check from late loading Chang S. Bae
2026-09-01 23:16 ` [PATCH RFC 6/8] x86/microcode/intel: Apply minimum revision check to early loading Chang S. Bae
2026-09-01 23:16 ` [PATCH RFC 7/8] x86/microcode: Introduce iterative late loading Chang S. Bae
2026-09-01 23:16 ` [PATCH RFC 8/8] x86/microcode/intel: Select the lowest loadable revision for iterative loading Chang S. Bae
2026-09-08 23:07 ` [PATCH 0/8] x86/microcode: Address GNR errata and follow-up Chang S. Bae

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=0bfbb372-31cc-42af-b485-001f9a64f3b5@intel.com \
    --to=dave.hansen@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sohil.mehta@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®