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

clocksource: hyper-v: Remove support for stimer interrupts in message mode

2026-08-24T00:36:14+00:00

In Hyper-V versions prior to WS2016/Win10, Hyper-V synthetic timers interrupt the guest by delivering a message that is initially handled by the Linux VMBus driver. Starting with WS2016/Win10, Hyper-V can deliver stimer interrupts directly to an assigned interrupt vector without involving the VMBus driver. This is called "Direct Mode". With the overall removal of Linux support for running on Hyper-V hosts earlier than WS2016 and Windows 10, it's no longer necessary to support the legacy message-based delivery. Remove that delivery mechanism and always use Direct Mode. If for some reason, the Hyper-V host does not enumerate Direct Mode, output an error message but continue to run using the LAPIC timer instead of an stimer. With these changes, the VMBus driver no longer calls the stimer interrupt service routine. This removal has a broader benefit in unblocking the disentangling of VMBus code and stimer code, as they should be independent of each other. The final disentangling will come as a follow-on patch set. Signed-off-by: Michael Kelley Signed-off-by: Wei Liu

x86/hyperv: reserve more vectors

2026-08-24T00:23:35+00:00

Microsoft Hypervisor delivers three vectors to the NT HAL running in the root partition and refuses to map a device interrupt to any of them when interrupt remapping is not available in the system. As of writing, the nested MSHV setup has no interrupt remapping capability. The three vectors are: HAL_NT_APC_VECTOR 0x1F HAL_NT_DPC_VECTOR 0x2F HAL_NT_CLOCK_IPI_VECTOR 0xD2 0x1F is below FIRST_EXTERNAL_VECTOR so the vector allocator never hands it out, but 0x2F and 0xD2 are both inside the allocatable range and are handed out once enough vectors are in use. Mapping such an interrupt then fails with HV_STATUS_INVALID_PARAMETER, and the interrupt is never delivered. Reserve all three next to the hypervisor debug vectors that are already kept out of the allocator's hands. Reviewed-by: Michael Kelley Signed-off-by: Wei Liu

Merge tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-15T09:55:17+00:00

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 - 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 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 ...

x86/irq: Make irqstats array based

2026-05-26T14:21:12+00:00

Having the x86 specific interrupt statistics as a data structure with individual members instead of an array is just stupid as it requires endless copy and paste in arch_show_interrupts() and arch_irq_stat_cpu(), where the latter does not even take the latest interrupt additions into account. The resulting #ifdef orgy is just disgusting. Convert it to an array of counters, which does not make a difference in the actual interrupt hotpath increment as the array index is constant and therefore not any different than the member based access. But in arch_show_interrupts() and arch_irq_stat_cpu() this just turns into a loop, which reduces the text size by ~2k (~12%): text data bss dec hex filename 19643 15250 904 35797 8bd5 ../build/arch/x86/kernel/irq.o 17355 15250 904 33509 82e5 ../build/arch/x86/kernel/irq.o Adding a new vector or software counter only requires to update the table and everything just works. Using the core provided emit function which speeds up 0 outputs makes it significantly faster. Signed-off-by: Thomas Gleixner Tested-by: Michael Kelley Reviewed-by: Radu Rendec Link: https://patch.msgid.link/20260517194931.196070643@kernel.org

treewide: Explicitly include the x86 CPUID headers

2026-05-06T12:29:59+00:00

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 since it references the CPUID_EAX..EDX symbols without using the CPUID APIs. Note, this allows removing the inclusion of from within next. That allows the CPUID API headers to include without introducing a circular dependency. Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de

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

Drivers: hv: Move add_interrupt_randomness() to hypervisor callback sysvec

2026-04-04T19:01:56+00:00

The Hyper-V ISRs, for normal guests and when running in the hypervisor root patition, are calling add_interrupt_randomness() as a primary source of entropy. The call is currently in the ISRs as a common place to handle both x86/x64 and arm64. On x86/x64, hypervisor interrupts come through a custom sysvec entry, and do not go through a generic interrupt handler. On arm64, hypervisor interrupts come through an emulated GICv3. GICv3 uses the generic handler handle_percpu_devid_irq(), which does not do add_interrupt_randomness() -- unlike its counterpart handle_percpu_irq(). But handle_percpu_devid_irq() is now updated to do the add_interrupt_randomness(). So add_interrupt_randomness() is now needed only in Hyper-V's x86/x64 custom sysvec path. Move add_interrupt_randomness() from the Hyper-V ISRs into the Hyper-V x86/x64 custom sysvec path, matching the existing STIMER0 sysvec path. With this change, add_interrupt_randomness() is no longer called from any device drivers, which is appropriate. Signed-off-by: Michael Kelley Signed-off-by: Thomas Gleixner Acked-by: Wei Liu Link: https://patch.msgid.link/20260402202400.1707-3-mhklkml@zohomail.com

x86/hyperv: print out reserved vectors in hexadecimal

2026-02-24T17:10:44+00:00

Signed-off-by: Wei Liu