Remove __maybe_unused from variables and functions that are referenced
unconditionally.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260630083031.683508-2-thorsten.blum@linux.dev

It is not only used in the microcode loader anymore and the platform ID is
cached in the cpuinfo_x86 structure so move the getter to Intel CPU-specific
code.

No functional changes.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com

Pull x86 microcode loader updates from Borislav Petkov:

 - Move the zero-revision fixup for AMD microcode to the patch level
   retrieval function and restrict it to Zen family processors, ensuring
   patch level arithmetic always operates on a valid revision

 - Fix an incorrect comment about which CPUID bit is checked when
   determining whether the microcode loader should be disabled

 - Add the latest Intel microcode revision data for a broad range of
   processor models and steppings and add the script which generates the
   header of minimum expected Intel microcode revisions

* tag 'x86_microcode_for_v7.2_rc1' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip:
  x86/microcode/AMD: Move the no-revision fixup to get_patch_level()
  x86/microcode: Fix comment in microcode_loader_disabled()
  scripts/x86/intel: Add a script to update the old microcode list
  x86/microcode/intel: Refresh old_microcode defines with Nov 2025 release

Pull x86 cpuid updates from Ingo Molnar:

 - CPUID API updates (Ahmed S. Darwish):
    - Introduce a centralized CPUID parser
    - Introduce a centralized CPUID data model
    - Introduce <asm/cpuid/leaf_types.h>
    - Rename cpuid_leaf()/cpuid_subleaf() APIs
    - treewide: Explicitly include the x86 CPUID headers

 - Update to x86-cpuid-db v3.1 (Maciej Wieczor-Retman)

 - Continued removal of pre-i586 support and related simplifications
   (Ingo Molnar)

 - Add Intel CPU model number for rugged Panther Lake (Tony Luck)

 - Misc fixes, updates and cleanups by Arnd Bergmann, Chao Gao, Lukas
   Bulwahn, Sohil Mehta, Maciej Wieczor-Retman.

* tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (25 commits)
  x86/cpu: Make CONFIG_X86_CX8 unconditional
  x86/cpu: Remove unused !CONFIG_X86_TSC code
  x86/cpuid: Update bitfields to x86-cpuid-db v3.1
  tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.1
  x86/cpu: Make CONFIG_X86_TSC unconditional
  MAINTAINERS: Drop obsolete FPU EMULATOR section
  x86/cpu: Fix a F00F bug warning and clean up surrounding code
  x86/cpu: Add Intel CPU model number for rugged Panther Lake
  x86/cpuid: Introduce a centralized CPUID parser
  x86/cpu: Introduce a centralized CPUID data model
  x86/cpuid: Introduce <asm/cpuid/leaf_types.h>
  x86/cpuid: Rename cpuid_leaf()/cpuid_subleaf() APIs
  x86/cpu: Do not include the CPUID API header in asm/processor.h
  Documentation: core-api/cpu_hotplug: Remove stale cpu0_hotplug docs
  x86/cpu, cpufreq: Remove AMD ELAN support
  x86/fpu: Remove the math-emu/ FPU emulation library
  x86/fpu: Remove the 'no387' boot option
  x86/fpu: Remove MATH_EMULATION and related glue code
  treewide: Explicitly include the x86 CPUID headers
  x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
  ...

On machines which don't have microcode applied yet, the revision is 0.
However, this doesn't work with the Zen family/model/stepping patch
arithmetic. So move the fixup to the patch level getter function and
this way make sure the patch level is always proper and thus the
arithmetic always works.

And now that it can be called on any family, make this Zen-only.

Assisted-by: claude/claude-opus-4-6
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20260530024213.86137-1-bp@kernel.org

Patch in Fixes: causes the usual:

  unchecked MSR access error: RDMSR from 0x17 at ... (intel_get_platform_id)
  Call Trace:
   early_init_intel
   early_cpu_init
   setup_arch
   _printk
   start_kernel
   x86_64_start_reservations
   x86_64_start_kernel
   common_startup_64

because the kernel is booted in a guest.

In order to avoid it, this MSR access needs to be prevented when running
virtualized. That is usually done by checking X86_FEATURE_HYPERVISOR but
for this particular case it is too early yet.

The platform ID needs to be read as early as when microcode is loaded on
the BSP:

  load_ucode_bsp ... -> get_microcode_blob ... -> intel_find_matching_signature

and by that time, CPUID leafs haven't been parsed yet.

The microcode loader already has logic to check early whether the kernel
is running virtualized so make that globally available to arch/x86/. The
query whether running virtualized is getting more and more prominent in
recent times so might as well make it an arch-global var which the rest
of the code can use.

Fixes: d8630b67ca1ed ("x86/cpu: Add platform ID to CPU info structure")
Reported-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Tested-by: Binbin Wu <binbin.wu@linux.intel.com>
Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com

The code in microcode_loader_disabled() actually checks for the bit 31
in CPUID[1]:ECX being set. Update the comment to match the code.

No functional change intended.

Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260512152754.671760-1-xiaoyao.li@intel.com

Modify all CPUID call sites which implicitly include any of the CPUID
headers to explicitly include them instead.

For KVM's reverse_cpuid.h, just include <asm/cpuid/types.h> since it
references the CPUID_EAX..EDX symbols without using the CPUID APIs.

Note, this allows removing the inclusion of <asm/cpuid/api.h> from within
<asm/processor.h> next.  That allows the CPUID API headers to include
<asm/processor.h> without introducing a circular dependency.

Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de

Update the minimum expected revisions of Intel microcode based on the
microcode-20251111 (November 2025) release.

Add an SPDX header as well as a comment to specify that the file is
auto-generated. While at it, remove an extra space before the model
field to match the formatting of the other fields.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://patch.msgid.link/20260407014226.1169040-2-sohil.mehta@intel.com

Intel sometimes has CPUs with identical family/model/stepping but
which need different microcode. These CPUs are differentiated with the
platform ID.

The Intel "microcode-20250512" release was used to generate the
existing contents of intel-ucode-defs.h. Use that same release and add
the platform mask to the definitions.

This makes the list a few entries longer because some CPUs previously
that shared a definition now need two or more. for example for the
ancient Pentium III there are two CPUs that differ only in their
platform and have two different microcode versions (note:
.driver_data is the microcode version):

	{ ..., .model = 0x05, .steppings = 0x0001, .platform_mask = 0x01, .driver_data = 0x40 },
	{ ..., .model = 0x05, .steppings = 0x0001, .platform_mask = 0x08, .driver_data = 0x45 },

Another example is the state-of-the-art Granite Rapids:

	{ ...,  .model = 0xad, .steppings = 0x0002, .platform_mask = 0x20, .driver_data = 0xa0000d1 },
	{ ...,  .model = 0xad, .steppings = 0x0002, .platform_mask = 0x95, .driver_data = 0x10003a2 },

As you can see, this differentiation with platform ID has been
necessary for a long time and is still relevant today.

Without the platform matching, the old microcode table is incomplete.
For instance, it might lead someone with a Pentium III, platform 0x0,
and microcode 0x40 to think that they should have microcode 0x45,
which is really only for platform 0x4 (.platform_mask==0x08).

In practice, this meant that folks with fully updated microcode were
seeing "Vulnerable" in the "old_microcode" file.

1. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

Closes: https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.com/
Fixes: 4e2c719782a8 ("x86/cpu: Help users notice when running old Intel microcode")
Reported-by: Jon Kohler <jon@nutanix.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Tested-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/all/3ECBB974-C6F0-47A7-94B6-3646347F1CC2@nutanix.com/
Link: https://patch.msgid.link/20260304181024.76E3F038@davehans-spike.ostc.intel.com