xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Георгий Зайцев" <zaytsevgu@gmail.com>
Cc: xen-devel@lists.xen.org, Sergey Kovalev <valor@list.ru>
Subject: Re: Fwd: [BUG] Windows is frozen after restore from snapshot
Date: Fri, 23 Apr 2021 15:40:01 +0200	[thread overview]
Message-ID: <d4fcc303-24c0-6f35-f3d1-d514eeea022c@suse.com> (raw)
In-Reply-To: <CADyHojFyzqRKHp4aWUFysnHbb3i0tMvM6wEAEd8Y1HHwGkncyQ@mail.gmail.com>

On 23.04.2021 15:30, Георгий Зайцев wrote:
> 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

So I misunderstood Sergey's original mail - HPET_TN_PERIODIC is clear
immediately after restore, and becomes set some time later. That's
still nothing we can do behind the OSes back. If the OS has cleared
the bit, we need to keep it clear.

Jan

> 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
>>
> 



  reply	other threads:[~2021-04-23 13:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6237e102-f2cf-a66e-09b6-954ebfe28f8c@list.ru>
2021-04-23 10:22 ` Sergey Kovalev
2021-04-23 12:30   ` Jan Beulich
2021-04-23 12:55     ` Sergey Kovalev
2021-04-23 13:10       ` Георгий Зайцев
2021-04-23 13:21         ` Jan Beulich
2021-04-23 13:30           ` Георгий Зайцев
2021-04-23 13:40             ` Jan Beulich [this message]
2021-04-23 15:08   ` Roger Pau Monné
2021-04-23 16:19     ` Sergey Kovalev
2021-04-24  0:39       ` Tamas K Lengyel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4fcc303-24c0-6f35-f3d1-d514eeea022c@suse.com \
    --to=jbeulich@suse.com \
    --cc=valor@list.ru \
    --cc=xen-devel@lists.xen.org \
    --cc=zaytsevgu@gmail.com \
    --subject='Re: Fwd: [BUG] Windows is frozen after restore from snapshot' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).