On 21.03.2025 10:50, Mykola Kvach wrote: > On Thu, Mar 13, 2025 at 5:34 PM Jan Beulich <jbeul...@suse.com> wrote: >> On 05.03.2025 10:11, Mykola Kvach wrote: >>> +void watchdog_domain_resume(struct domain *d) >>> +{ >>> + unsigned int i; >>> + >>> + spin_lock(&d->watchdog_lock); >>> + >>> + for ( i = 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ ) >>> + { >>> + if ( test_bit(i, &d->watchdog_inuse_map) ) >>> + { >>> + set_timer(&d->watchdog_timer[i].timer, >>> + NOW() + SECONDS(d->watchdog_timer[i].timeout)); >> >> The timeout may have almost expired before suspending; restoring to the >> full original period feels wrong. At the very least, if that's indeed >> intended behavior, imo this needs spelling out explicitly. > > It takes some time to wake up the domain, but the watchdog timeout is > reset by a userspace daemon. As a result, we can easily encounter a > watchdog trigger during the resume process.
Which may mean the restoring is done too early, or needs doing in two phases. > It looks like we should > stop the watchdog timer from the guest, and in that case, we can drop > all changes related to the watchdog in this patch series. Except that then you require a guest to be aware of host suspend. Which may not be desirable. Jan