Thanks, but now I'll need to understand what your quoted "frozen" and
> "unfrozen" mean. Plus obviously comparators and main counter are also
> different, and it's there where I suspect the issue is

"frozen" - this is initial snapshot which takes about from 30 seconds to 1
minute after restore to start dispatching timer interrupts to windows guest
"unfrozen" - this is state which taken after restoring "frozen" one and
waiting 90 seconds when guest start receiving interrupts and starts working
as expected

we also made some another snapshots (again after restoring from initial
"frozen" one) when system still in 'freezed" state (about ~20-30 seconds
from start of restore process) and in this snapshots HPET state stays the
same as in initial "frozen" state except mc64 field:
capabiliy: f424008086a201
res0: 0
config: 3
res1: 0
isr: 0
res2: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0]
mc64: 9bafb6e4e
res3: 0
timer0:
        config: f0000000002934
        cmp: fd4aa84c
        fsb: 0
        res4: 0
timer1:
        config: f0000000000130
        cmp: ffffffff
        fsb: 0
        res4: 0
timer2:
        config: f0000000000130
        cmp: ffffffff
        fsb: 0
        res4: 0
period[0] = ee6b2
period[1] = 0
period[2] = 0

пт, 23 апр. 2021 г. в 16:21, Jan Beulich <jbeulich@suse.com>:

> On 23.04.2021 15:10, Георгий Зайцев wrote:
> >>
> >> Since
> >> you've taken apart saved state, could you supply the full set of
> >> values (ideally multiple ones, if you happen to have them, plus
> >> ones where the problem didn't occur, to allow someone perhaps
> >> spot a pattern)?
> >>
> >
> > Here is full HPET state from "frozen" snapshot according to hvm_hw_hpet
> > structure:
> >
> > capabiliy: f424008086a201
> > res0: 0
> > config: 3
> > res1: 0
> > isr: 0
> > res2: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0,
> > 0, 0]
> > mc64: 97b90bc74
> > res3: 0
> > timer0:
> >         config: f0000000002934
> >         cmp: fd4aa84c
> >         fsb: 0
> >         res4: 0
> > timer1:
> >         config: f0000000000130
> >         cmp: ffffffff
> >         fsb: 0
> >         res4: 0
> > timer2:
> >         config: f0000000000130
> >         cmp: ffffffff
> >         fsb: 0
> >         res4: 0
> > period[0] = ee6b2
> > period[1] = 0
> > period[2] = 0
> >
> > This one taken from snapshot of "unfrozen" one:
> >
> > capabiliy: f424008086a201
> > res0: 0
> > config: 3
> > res1: 0
> > isr: 0
> > res2: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0,
> > 0, 0]
> > mc64: acbd23c57
> > res3: 0
> > timer0:
> >         config: f000000000293c
> >         cmp: acbd3761b
> >         fsb: 0
> >         res4: 0
> > timer1:
> >         config: f0000000000130
> >         cmp: ffffffff
> >         fsb: 0
> >         res4: 0
> > timer2:
> >         config: f0000000000130
> >         cmp: ffffffff
> >         fsb: 0
> >         res4: 0
> > period[0] = ee6b2
> > period[1] = 0
> > period[2] = 0
> >
> > The only difference is HPET_TN_PERIODIC flag for timers[0].config value
>
> Thanks, but now I'll need to understand what your quoted "frozen" and
> "unfrozen" mean. Plus obviously comparators and main counter are also
> different, and it's there where I suspect the issue is.
>
> Jan
>