From: "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>
To: David Laight <david.laight.linux@gmail.com>,
"Bae, Chang Seok" <chang.seok.bae@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"tglx@kernel.org" <tglx@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v3] x86/microcode/intel: Reject problematic loading on Granite Rapids systems
Date: Thu, 17 Sep 2026 13:35:18 +0000 [thread overview]
Message-ID: <SA1PR11MB88578272D7F9B15DA85F9ABA92B82@SA1PR11MB8857.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20260917101455.3e1ac9a5@pumpkin>
> > Microcode updates can usually jump revisions. However, there is an
> > erratum on Granite Rapids systems. If they "jump over" revision
> > 0x1000405, they result in #MC. Avoid it.
>
> A probably silly question.
> Is it valid to downgrade microcode?
Within SVN in theory it can be done
In practice, unless you have very special circumstances (and check with Intel if the exact downgrade you have in mind has been tested for downgrading) I would very strongly recommend against doing so. It may appear to work, but note that
A -> B -> A
Is NOT identical to just
A (staying at A)
as part of the microcode load, some microcode runs as "setup" which may change settings in the CPU (versus runtime behavior changes) -- and that setup step is not undone as you go back to A.... which means you run A with a (partial or whole) setup of B.
next prev parent reply other threads:[~2026-09-17 13:35 UTC|newest]
Thread overview: 32+ 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
2026-09-09 0:13 ` Borislav Petkov
2026-09-09 0:39 ` Chang S. Bae
2026-09-09 0:14 ` Andrew Cooper
2026-09-16 22:59 ` [PATCH v3] " Chang S. Bae
2026-09-17 9:14 ` David Laight
2026-09-17 10:50 ` Andrew Cooper
2026-09-17 13:35 ` Van De Ven, Arjan [this message]
2026-09-17 17:52 ` Sohil Mehta
2026-09-17 18:11 ` Chang S. Bae
2026-09-17 18:43 ` Van De Ven, Arjan
2026-09-17 18:25 ` Chang S. Bae
2026-09-18 0:41 ` [tip: x86/urgent] " tip-bot2 for Chang S. Bae
2026-09-18 6:54 ` [PATCH v3] " Ingo Molnar
2026-09-18 15:37 ` Borislav Petkov
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=SA1PR11MB88578272D7F9B15DA85F9ABA92B82@SA1PR11MB8857.namprd11.prod.outlook.com \
--to=arjan.van.de.ven@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david.laight.linux@gmail.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®