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

[Sean Christopherson <seanjc@google.com>]

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.