linux.git/arch/x86/kernel/cpu/amd.c, branch v7.1 Linux kernel source tree x86/CPU/AMD: Add more Zen6 models 2026-06-01T17:31:09+00:00 Pratik Vishwakarma Pratik.Vishwakarma@amd.com 2026-05-30T06:18:18+00:00 b5f53e6d3d32f2884d71500bb6d773c7bfe21f2e Family 0x1a, models 0xd0 - 0xef are Zen6, so add them to the range which sets X86_FEATURE_ZEN6. [ bp: Massage commit message. ] Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260530061819.9721-1-Pratik.Vishwakarma@amd.com 
Family 0x1a, models 0xd0 - 0xef are Zen6, so add them to the range which sets
X86_FEATURE_ZEN6.

  [ bp: Massage commit message. ]

Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260530061819.9721-1-Pratik.Vishwakarma@amd.com
x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache 2026-05-12T03:06:36+00:00 Prathyushi Nangia prathyushi.nangia@amd.com 2025-12-09T16:01:33+00:00 c21b90f77687075115d989e53a8ec5e2bb427ab1 Make sure resources are not improperly shared in the op cache and cause instruction corruption this way. Signed-off-by: Prathyushi Nangia <prathyushi.nangia@amd.com> Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Make sure resources are not improperly shared in the op cache and
cause instruction corruption this way.

Signed-off-by: Prathyushi Nangia <prathyushi.nangia@amd.com>
Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86/CPU: Fix FPDSS on Zen1 2026-04-17T13:04:42+00:00 Borislav Petkov (AMD) bp@alien8.de 2026-04-07T09:40:03+00:00 e55d98e7756135f32150b9b8f75d580d0d4b2dd3 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Zen1's hardware divider can leave, under certain circumstances, partial
results from previous operations.  Those results can be leaked by
another, attacker thread.

Fix that with a chicken bit.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86/CPU/AMD: Print AGESA string from DMI additional information entry 2026-04-01T18:54:16+00:00 Yazen Ghannam yazen.ghannam@amd.com 2026-03-07T14:10:24+00:00 bc91133e260c8113c1119073c03b93c12aa41738 Type 40 entries (Additional Information) are summarized in section 7.41 as part of the SMBIOS specification. Generally, these entries aren't interesting to save. However on some AMD Zen systems, the AGESA version is stored here. This is useful to save to the kernel message logs for debugging. It can be used to cross-reference issues. Implement an iterator for the Additional Information entries. Use this to find and print the AGESA string. Do so in AMD code, since the use case is AMD-specific. [ bp: Match only "AGESA". ] Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Co-developed-by: "Mario Limonciello (AMD)" <superm1@kernel.org> Signed-off-by: "Mario Limonciello (AMD)" <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Link: https://patch.msgid.link/20260307141024.819807-6-superm1@kernel.org 
Type 40 entries (Additional Information) are summarized in section 7.41 as
part of the SMBIOS specification.  Generally, these entries aren't interesting
to save.

However on some AMD Zen systems, the AGESA version is stored here. This is
useful to save to the kernel message logs for debugging. It can be used to
cross-reference issues.

Implement an iterator for the Additional Information entries. Use this to find
and print the AGESA string. Do so in AMD code, since the use case is
AMD-specific.

  [ bp: Match only "AGESA". ]

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Co-developed-by: "Mario Limonciello (AMD)" <superm1@kernel.org>
Signed-off-by: "Mario Limonciello (AMD)" <superm1@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Link: https://patch.msgid.link/20260307141024.819807-6-superm1@kernel.org
Merge tag 'x86_cleanups_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 2026-02-11T02:43:03+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-11T02:43:03+00:00 9fbb4810404a02e0081d43d5c6b0b4c9057e15d6 Pull x86 cleanups from Borislav Petkov: - The usual set of cleanups and simplifications all over the tree * tag 'x86_cleanups_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/segment: Use MOVL when reading segment registers selftests/x86: Clean up sysret_rip coding style x86/mm: Hide mm_free_global_asid() definition under CONFIG_BROADCAST_TLB_FLUSH x86/crash: Use set_memory_p() instead of __set_memory_prot() x86/CPU/AMD: Simplify the spectral chicken fix x86/platform/olpc: Replace strcpy() with strscpy() in xo15_sci_add() x86/split_lock: Remove dead string when split_lock_detect=fatal 
Pull x86 cleanups from Borislav Petkov:

 - The usual set of cleanups and simplifications all over the tree

* tag 'x86_cleanups_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/segment: Use MOVL when reading segment registers
  selftests/x86: Clean up sysret_rip coding style
  x86/mm: Hide mm_free_global_asid() definition under CONFIG_BROADCAST_TLB_FLUSH
  x86/crash: Use set_memory_p() instead of __set_memory_prot()
  x86/CPU/AMD: Simplify the spectral chicken fix
  x86/platform/olpc: Replace strcpy() with strscpy() in xo15_sci_add()
  x86/split_lock: Remove dead string when split_lock_detect=fatal
x86/CPU/AMD: Simplify the spectral chicken fix 2026-01-09T10:36:52+00:00 Borislav Petkov (AMD) bp@alien8.de 2025-12-30T11:07:31+00:00 736a2dcfdae72483a36793bc92182f33bd61d30e msr_set_bit() takes a bit number to set but MSR_ZEN2_SPECTRAL_CHICKEN_BIT is a bit mask. The usual pattern that code uses is a _BIT-named type macro instead of a mask. So convert it to a bit number to reflect that. Also, msr_set_bit() already does the reading and checking whether the bit needs to be set so use that instead of a local variable. Fixup tabbing while at it. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Link: https://patch.msgid.link/20251230110731.28108-1-bp@kernel.org 
msr_set_bit() takes a bit number to set but MSR_ZEN2_SPECTRAL_CHICKEN_BIT
is a bit mask. The usual pattern that code uses is a _BIT-named type
macro instead of a mask.

So convert it to a bit number to reflect that.

Also, msr_set_bit() already does the reading and checking whether the
bit needs to be set so use that instead of a local variable.

Fixup tabbing while at it.

No functional changes.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Link: https://patch.msgid.link/20251230110731.28108-1-bp@kernel.org
x86/cpu: Drop vestigial PBE logic in AMD/Hygon/Centaur/Cyrix 2025-12-14T08:57:13+00:00 Andrew Cooper andrew.cooper3@citrix.com 2025-11-26T12:51:47+00:00 0bc03750deefc5fdab77b01c459bb1691c64c3c5 Besides formatting changes, this logic dates back to Linux 2.4.0-test11 in November 2000. Prior to "Massive cleanup of CPU detection and bug handling", c->x86_capability was a single u32 containing cpuid(1).edx, cpuid(0x80000001).edx, or a synthesis thereof. X86_FEATURE_AMD3D was defined as the top bit this single u32. After "Massive cleanup of CPU detection and bug handling", c->x86_capability became an array with AMD's extended feature leaf split away from Intel's basic feature leaf. AMD doc #20734-G states that 3DNow is only enumerated in the extended feature leaf, and that other vendors where using this bit too. i.e. AMD never produced a CPU which set bit 31 in the basic leaf, meaning that there's nothing to clear out in the first place. This logic looks like it was relevant in the pre-"Massive cleanup" world but ought to have been dropped when c->x86_capability was properly split. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Pu Wen <puwen@hygon.cn> Link: https://patch.msgid.link/20251126125147.880275-1-andrew.cooper3@citrix.com 
Besides formatting changes, this logic dates back to Linux 2.4.0-test11 in
November 2000.

Prior to "Massive cleanup of CPU detection and bug handling",
c->x86_capability was a single u32 containing cpuid(1).edx,
cpuid(0x80000001).edx, or a synthesis thereof.  X86_FEATURE_AMD3D was
defined as the top bit this single u32.

After "Massive cleanup of CPU detection and bug handling",
c->x86_capability became an array with AMD's extended feature leaf split
away from Intel's basic feature leaf.

AMD doc #20734-G states that 3DNow is only enumerated in the extended
feature leaf, and that other vendors where using this bit too.  i.e. AMD
never produced a CPU which set bit 31 in the basic leaf, meaning that
there's nothing to clear out in the first place.

This logic looks like it was relevant in the pre-"Massive cleanup" world
but ought to have been dropped when c->x86_capability was properly split.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Pu Wen <puwen@hygon.cn>
Link: https://patch.msgid.link/20251126125147.880275-1-andrew.cooper3@citrix.com
x86/cpu/amd: Use ZEN_MODEL_STEP_UCODE() for erratum_1386_microcode[] 2025-12-14T08:55:47+00:00 Andrew Cooper andrew.cooper3@citrix.com 2025-11-26T11:34:42+00:00 a2aabcfc6015b6196f161b6bf4df1519ab09c3e1 ... to simplify the result. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20251126113442.877024-1-andrew.cooper3@citrix.com 
... to simplify the result.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20251126113442.877024-1-andrew.cooper3@citrix.com
x86/cpu/amd: Correct the microcode table for Zenbleed 2025-12-14T08:54:46+00:00 Andrew Cooper andrew.cooper3@citrix.com 2025-11-26T13:03:52+00:00 fb7bfa31b8e8569f154f2fe0ea6c2f03c0f087aa The good revisions are tied to exact steppings, meaning it's not valid to match on model number alone, let alone a range. This is probably only a latent issue. From public microcode archives, the following CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the model ranges. They're likely pre-production steppings, and likely didn't get Zenbleed microcode, but it's still incorrect to compare them to a different steppings revision. Either way, convert the logic to use x86_match_min_microcode_rev(), which is the preferred mechanism. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: x86@kernel.org Link: https://patch.msgid.link/20251126130352.880424-1-andrew.cooper3@citrix.com 
The good revisions are tied to exact steppings, meaning it's not valid to
match on model number alone, let alone a range.

This is probably only a latent issue.  From public microcode archives, the
following CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the
model ranges.  They're likely pre-production steppings, and likely didn't get
Zenbleed microcode, but it's still incorrect to compare them to a different
steppings revision.

Either way, convert the logic to use x86_match_min_microcode_rev(), which is
the preferred mechanism.

Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: x86@kernel.org
Link: https://patch.msgid.link/20251126130352.880424-1-andrew.cooper3@citrix.com
Merge tag 'x86_misc_for_6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 2025-12-02T22:16:42+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-12-02T22:16:42+00:00 e2aa39b368bb147afe8f6bd63d962494354f6498 Pull misc x86 updates from Dave Hansen: "The most significant are some changes to ensure that symbols exported for KVM are used only by KVM modules themselves, along with some related cleanups. In true x86/misc fashion, the other patch is completely unrelated and just enhances an existing pr_warn() to make it clear to users how they have tainted their kernel when something is mucking with MSRs. Summary: - Make MSR-induced taint easier for users to track down - Restrict KVM-specific exports to KVM itself" * tag 'x86_misc_for_6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possible x86/mm: Drop unnecessary export of "ptdump_walk_pgd_level_debugfs" x86/mtrr: Drop unnecessary export of "mtrr_state" x86/bugs: Drop unnecessary export of "x86_spec_ctrl_base" x86/msr: Add CPU_OUT_OF_SPEC taint name to "unrecognized" pr_warn(msg) 
Pull misc x86 updates from Dave Hansen:
 "The most significant are some changes to ensure that symbols exported
  for KVM are used only by KVM modules themselves, along with some
  related cleanups.

  In true x86/misc fashion, the other patch is completely unrelated and
  just enhances an existing pr_warn() to make it clear to users how they
  have tainted their kernel when something is mucking with MSRs.

  Summary:

   - Make MSR-induced taint easier for users to track down

   - Restrict KVM-specific exports to KVM itself"

* tag 'x86_misc_for_6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possible
  x86/mm: Drop unnecessary export of "ptdump_walk_pgd_level_debugfs"
  x86/mtrr: Drop unnecessary export of "mtrr_state"
  x86/bugs: Drop unnecessary export of "x86_spec_ctrl_base"
  x86/msr: Add CPU_OUT_OF_SPEC taint name to "unrecognized" pr_warn(msg)