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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aXO8I6xuZyZB7CxV@google.com>
Date: Fri, 23 Jan 2026 10:21:23 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Alexander Graf <graf@...zon.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, hpa@...or.com, 
	x86@...nel.org, Paolo Bonzini <pbonzini@...hat.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, Jan 15, 2026, Alexander Graf wrote:
> During Windows Server 2025 hibernation, I have seen Windows' calculation
> of interrupt target time get skewed over the hypervisor view of the same.

> This can cause 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. Those manifest as bugchecks 0x9f and 0xa0 during
> hibernation, typically in the resume path.
> 
> To work around this problem, we can delay timers that get created with a
> target time in the past by a tiny bit (10µs) to give the guest CPU time
> to process real work and make forward progress, hopefully recovering its
> interrupt logic in the process. While this small delay can marginally
> reduce accuracy of guest timers, 10µs are within the noise of VM
> entry/exit overhead (~1-2 µs) so I do not expect to see real world impact.

There is a lot of hope piled into this.  And *always* padding the count makes me
more than a bit uncomfortable.  If the skew is really due to a guest bug and not
something on the host's side, i.e. if this isn't just a symptom of a real bug that
can be fixed and the _only_ option is to chuck in a workaround, then I would
strongly prefer to be as conservative as possible.  E.g. is it possible to
precisely detect this scenario and only add the delay when the guest appears to
be stuck?

> To still provide some level of visibility when this happens, add a trace
> point that clearly shows the discrepancy between the target time and the
> current time.

This honestly doesn't seem all that useful.  As a debug tool, sure, but once the
workaround is in place, it doesn't seem like it'll add a lot of value since it
would require the end user to be aware of the workaround in the first place.

If we really want something, a stat or a pr_xxx_once() (even though I generally
dislike those) seems like it'd be more helpful.