linux-kernel - Re: [PATCH] kvm: hyper-v: Delay firing of expired stimers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <771bca8b2952cf594f23eb451d791b5a29275511.camel@infradead.org>
Date: Fri, 23 Jan 2026 16:37:19 -0800
From: David Woodhouse <dwmw2@...radead.org>
To: Alexander Graf <graf@...zon.com>, kvm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, hpa@...or.com, x86@...nel.org, Paolo
 Bonzini <pbonzini@...hat.com>, Sean Christopherson <seanjc@...gle.com>,
 Vitaly Kuznetsov <vkuznets@...hat.com>, nh-open-source@...zon.com,
 gurugubs@...zon.com, jalliste@...zon.co.uk,  Michael Kelley
 <mhklinux@...look.com>, John Starks <jostarks@...rosoft.com>
Subject: Re: [PATCH] kvm: hyper-v: Delay firing of expired stimers

On Thu, 2026-01-15 at 14:15 +0000, Alexander Graf wrote:
> 
> +		 *
> +		 * However, there are cases during hibernation when
> Windows's
> +		 * interrupt count calculation can go out of sync
> with KVM's
> +		 * view of it, causing Windows to emit timer events
> in the past
> +		 * for events that do not fire yet according to the
> real time
> +		 * source. This then leads to interrupt storms in
> the guest
> +		 * which slow down execution to a point where
> watchdogs trigger.

Do these 'cases during hibernation' occur when the TSC page hasn't been
set up yet in the new environment?

I note get_time_ref_counter() falls back to get_kvmclock_ns() in that
case, but get_kvmclock_ns() is known to be hosed. We stopped using it
for Xen timers for precisely that reason; see commit 451a707813aee.

The detail in this case might be different, but we really should
*understand* why stimer_start() has a different idea of the time than
the guest does, and address that properly.

FWIW it's probably in the noise and not the actual cause of this error,
but it looks like stimer_start() might benefit from using
kvm_get_monotonic_and_clockread(), to get an actual paired reading from
the same TSC read instead of calling get_time_ref_counter() and then
*later* calling ktime_get() to read CLOCK_MONOTONIC at a slightly
different time. You can pass a TSC reading into get_time_ref_counter(),
can't you? Let callers who don't care pass rdtsc() in.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)