Re: [XEN PATCH] x86/vhpet: Add option to always fire hpet timer on resume

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Aug 27, 2025 at 09:01:08AM +0300, Vyacheslav Legoshin wrote:
> The following issue was observed on Windows 10 21H2 x64+: when the domain state
> is saved while all cores are executing the 'halt' instruction,

I assume this when executing `xl save` or equivalent command from a
different toolstack?

IIRC in that case the guest would be paused while the memory dump to
disk is done, and hence guest vCPUs won't be executing the `halt`
instruction, they wouldn't be executing at all.

> and the memory
> save takes a relatively long time (tens of seconds), the HPET counter may
> overflow as follows:
> counter  = 11243f3e4a
> comparator = 910cb70f
> 
> In such cases, the fix implemented in commit
> b144cf45d50b603c2909fc32c6abf7359f86f1aa does not work (because the 'diff' is
> not negative), resulting in the guest VM becoming unresponsive for
> approximately 30 seconds.
> 
> This patch adds an option to always adjust the HPET timer to fire immediately
> after restore.

What happens if the guest is left running after the save?  I assume
that using `xl save -c <domain>` would leave the domain in a similarly
wedged state, and your proposed workaround won't be effective there,
since there's no restoring process?  Or that's not the case there
because Xen is still keeping track of the internal timer, and would
set an interrupt as pending anyway?

Should we maybe store the last guest time at context save, and check
against that to see whether comparators should have triggered, instead
of playing this games?

Thanks, Roger.