Linux technique idea: Hyper-V guest fingerprint via /proc/interrupts (LOC vs HVS/HYP)

[nks0005]

Summary

I looked for Linux-side checks that complement existing Hyper-V detection (CPUID Microsoft Hv, HYPERVISOR_BIT, etc.). Upstream vmaware.hpp reads several /proc paths but does not open /proc/interrupts. I’d like to discuss whether a low-cost read of interrupt accounting lines could add corroborating signal for Hyper-V Linux guests, especially when clockevents use stimer0 instead of the local APIC timer.

This is not a replacement for CPUID; it’s a kernel-visible platform fingerprint tied to how Linux schedules ticks on Hyper-V (Hyper-V clocks: stimer0 preferred over LAPIC for clockevents).

Observation (Hyper-V guest, Linux)

On a 10-vCPU guest I see:

• LOC: — all zeros (Local timer interrupts)
• HVS: — large per-CPU counts (Hyper-V stimer0)
• HYP: — non-zero (Hypervisor callback)
• HRE: — zero in my snapshot (Hyper-V reenlightenment; may stay 0 depending on config/state)
• RES: — normal reschedule IPI traffic (not Hyper-V-specific; same axis as bare metal)

Snippet:

LOC:          0          0          0 ...   Local timer interrupts
RES:      43666      39699      58886 ...   Rescheduling interrupts
HYP:     168831      25742      56814 ...   Hypervisor callback interrupts
HRE:          0          0          0 ...   Hyper-V reenlightenment interrupts
HVS:    3250972    2755915    3225160 ...   Hyper-V stimer0 interrupts

Interpretation (scheduler / APIC view, not VMAware-specific): on Hyper-V guests, HVS often plays the role bare metal assigns to LOC for per-CPU tick/clockevent delivery; LOC=0 does not mean the scheduler tick is dead.

[NotRequiem]

yes, it's reliable

LOC = 0 is not enough, because the guest may be using the synthetic timer instead of the local APIC timer, but a non-zero HVS count is meaningful

However... if CPUID is fully masked and no Hyper-V enlightenments are exposed, I guess HVS should usually stay absent or zero. This is, if a hypervisor manages to bypass VMAware's CPUID checks on Linux, it will also bypass the Linux kernel itself from detecting Hyper-V and incrementing HVS

The actual interrupt handler increments that counter in sysvec_hyperv_stimer0, and Linux only installs that vector when Hyper-V init reaches hyperv_init() and ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE is true.

https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/mshyperv.c#L193-L204

That init path itself is gated by Hyper-V CPUID detection: ms_hyperv_platform() first requires boot_cpu_has(X86_FEATURE_HYPERVISOR), then checks the Hyper-V vendor leaf for "Microsoft Hv", and then requires the mandatory Hyper-V feature MSRs before returning success. However, the kernel returns before doing the MSR checks

https://github.com/torvalds/linux/blob/1590cf0329716306e948a8fc29f1d3ee87d3989f/arch/x86/kernel/cpu/mshyperv.c#L346-L373

That's why it's not added currently.

[nks0005]

Oh, I didn't know the Linux kernel handled Hyper-V detection that way.

Thanks for the explanation!

I'll dig into the kernel code and learn more.