linux.git/arch/x86/kernel/cpu, branch master

x86/resctrl: Only check Intel systems for SNC

2026-06-05T09:09:34+00:00

topology_num_nodes_per_package() reports values greater than one on certain
AMD systems resulting in resctrl's Intel model specific SNC detection
printing the confusing message:

   "CoD enabled system? Resctrl not supported"

Add a check for Intel systems before looking at the topology.

[ reinette: Add Closes tag, fix tag typos, rework changelog ]

Fixes: 59674fc9d0bf ("x86/resctrl: Fix SNC detection")
Reported-by: Babu Moger 
Signed-off-by: Tony Luck 
Signed-off-by: Reinette Chatre 
Signed-off-by: Ingo Molnar 
Tested-by: Babu Moger 
Link: https://patch.msgid.link/9849330f45ac86344cc5ac54df2d313906d70bc4.1780634584.git.reinette.chatre@intel.com
Closes: https://lore.kernel.org/lkml/37ac0376-43a3-4283-a3d5-4d57b3bec578@amd.com/

x86/CPU/AMD: Add more Zen6 models

2026-06-01T17:31:09+00:00

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 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://patch.msgid.link/20260530061819.9721-1-Pratik.Vishwakarma@amd.com

x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guest

2026-05-26T20:36:23+00:00

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 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Binbin Wu 
Reviewed-by: Xiaoyao Li 
Tested-by: Binbin Wu 
Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com

x86/mm: Disable broadcast TLB flush when PCID is disabled

2026-05-20T21:15:07+00:00

Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being
set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains
enabled.

There are two checks that decide whether the global ASID code runs,
mm_global_asid() and consider_global_asid(), that key off of the
X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three
CPUs, consider_global_asid() assigns it a global ASID, after which
flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero
PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set
results in a #GP:

  Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI
  CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full)
  Hardware name: ...
  RIP: 0010:broadcast_tlb_flush
  Code: ... 89 da 48 83 c8 07 <0f> 01 fe eb 08 cc cc cc ...
  Call Trace:
   
   flush_tlb_mm_range
   ptep_clear_flush
   wp_page_copy
   ? _raw_spin_unlock
   __handle_mm_fault
   handle_mm_fault
   do_user_addr_fault
   exc_page_fault
   asm_exc_page_fault

All processors that support broadcast TLB invalidation also have PCID support,
so it is only the "nopcid" scenario that is of concern. In this situation just
disable the broadcast TLB support using the CPUID dependency support by making
X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.

  [ bp: Massage commit message. ]

Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes")
Suggested-by: Dave Hansen 
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: Tom Lendacky 
Signed-off-by: Borislav Petkov (AMD) 
Acked-by: Rik van Riel 
Cc: 
Link: https://patch.msgid.link/b915acfd63e8b2a094fdeb8dc608738072518764.1779296450.git.thomas.lendacky@amd.com

Merge tag 'ras-urgent-2026-05-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-05-17T17:50:13+00:00

Pull MCE fix from Ingo Molnar:

 - Fix an MCE polling interval adjustment regression (Borislav Petkov)

* tag 'ras-urgent-2026-05-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mce: Restore MCA polling interval halving

x86/mce: Restore MCA polling interval halving

2026-05-13T15:38:35+00:00

RongQing reported that the MCA polling interval doesn't halve when an
error gets logged. It was traced down to the commit in Fixes:, because:

  mce_timer_fn()
  |-> mce_poll_banks()
  |-> machine_check_poll()
  |-> mce_log()

which will queue the work and return.

Now, back in mce_timer_fn():

        /*
         * Alert userspace if needed. If we logged an MCE, reduce the polling
         * interval, otherwise increase the polling interval.
         */
        if (mce_notify_irq())

<--- here we haven't ran the notifier chain yet so mce_need_notify is
not set yet so this won't hit and we won't halve the interval iv.

Now the notifier chain runs. mce_early_notifier() sets the bit, does
mce_notify_irq(), that clears the bit and then the notifier chain
a little later logs the error.

So this is a silly timing issue.

But, that's all unnecessary.

All it needs to happen here is, the "should we notify of a logged MCE"
mce_notify_irq() asks, should be simply a question to the mce gen pool:
"Are you empty?"

And that then turns into a simple yes or no answer and it all
JustWorks(tm).

So do that and also distribute the functionality where it belongs:
 - Print that MCE events have been logged in mce_log()
 - Trigger the mcelog tool specific work in the first notifier

As a result, mce_notify_irq() can go now.

Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector")
Reported-by: Li RongQing 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Qiuxu Zhuo 
Tested-by: Qiuxu Zhuo 
Link: https://lore.kernel.org/r/20260112082747.2842-1-lirongqing@baidu.com

x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache

2026-05-12T03:06:36+00:00

Make sure resources are not improperly shared in the op cache and
cause instruction corruption this way.

Signed-off-by: Prathyushi Nangia 
Co-developed-by: Borislav Petkov (AMD) 
Signed-off-by: Borislav Petkov (AMD) 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

Merge tag 'hyperv-next-signed-20260421' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2026-04-22T16:50:46+00:00

Pull Hyper-V updates from Wei Liu:

 - Fix cross-compilation for hv tools (Aditya Garg)

 - Fix vmemmap_shift exceeding MAX_FOLIO_ORDER in mshv_vtl (Naman Jain)

 - Limit channel interrupt scan to relid high water mark (Michael
   Kelley)

 - Export hv_vmbus_exists() and use it in pci-hyperv (Dexuan Cui)

 - Fix cleanup and shutdown issues for MSHV (Jork Loeser)

 - Introduce more tracing support for MSHV (Stanislav Kinsburskii)

* tag 'hyperv-next-signed-20260421' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
  x86/hyperv: Skip LP/VP creation on kexec
  x86/hyperv: move stimer cleanup to hv_machine_shutdown()
  Drivers: hv: vmbus: fix hyperv_cpuhp_online variable shadowing
  mshv: Add tracepoint for GPA intercept handling
  mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER
  tools: hv: Fix cross-compilation
  Drivers: hv: vmbus: Export hv_vmbus_exists() and use it in pci-hyperv
  mshv: Introduce tracing support
  Drivers: hv: vmbus: Limit channel interrupt scan to relid high water mark

x86/hyperv: Skip LP/VP creation on kexec

2026-04-22T06:23:25+00:00

After a kexec the logical processors and virtual processors already
exist in the hypervisor because they were created by the previous
kernel. Attempting to add them again causes either a BUG_ON or
corrupted VP state leading to MCEs in the new kernel.

Add hv_lp_exists() to probe whether an LP is already present by
calling HVCALL_GET_LOGICAL_PROCESSOR_RUN_TIME. When it succeeds the
LP exists and we skip the add-LP and create-VP loops entirely.

Also add hv_call_notify_all_processors_started() which informs the
hypervisor that all processors are online. This is required after
adding LPs (fresh boot) and is a no-op on kexec since we skip that
path.

Co-developed-by: Anirudh Rayabharam 
Signed-off-by: Anirudh Rayabharam 
Co-developed-by: Stanislav Kinsburskii 
Signed-off-by: Stanislav Kinsburskii 
Co-developed-by: Mukesh Rathor 
Signed-off-by: Mukesh Rathor 
Signed-off-by: Jork Loeser 
Reviewed-by: Stanislav Kinsburskii 
Signed-off-by: Wei Liu

x86/hyperv: move stimer cleanup to hv_machine_shutdown()

2026-04-22T06:23:25+00:00

Move hv_stimer_global_cleanup() from vmbus's hv_kexec_handler() to
hv_machine_shutdown() in the platform code. This ensures stimer cleanup
happens before the vmbus unload, which is required for root partition
kexec to work correctly.

Co-developed-by: Anirudh Rayabharam 
Signed-off-by: Anirudh Rayabharam 
Signed-off-by: Jork Loeser 
Reviewed-by: Stanislav Kinsburskii 
Signed-off-by: Wei Liu