From: Alexander Graf <agraf@suse.de>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
Nick Thomas <nick@bytemark.co.uk>
Subject: Re: [Qemu-devel] [PATCH] kvmclock: Ensure time in migration never goes backward
Date: Tue, 06 May 2014 09:16:38 +0200 [thread overview]
Message-ID: <53688C56.6020109@suse.de> (raw)
In-Reply-To: <20140505232343.GA20638@amt.cnet>
On 06.05.14 01:23, Marcelo Tosatti wrote:
> Hi Alexander,
>
> On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
>> When we migrate we ask the kernel about its current belief on what the guest
>> time would be.
> KVM_GET_CLOCK which returns the time in "struct kvm_clock_data".
Yes :)
>
>> However, I've seen cases where the kvmclock guest structure
>> indicates a time more recent than the kvm returned time.
> More details please:
>
> 1) By what algorithm you retrieve
> and compare time in kvmclock guest structure and KVM_GET_CLOCK.
> What are the results of the comparison.
> And whether and backwards time was visible in the guest.
I've managed to get my hands on a broken migration stream from Nick.
There I looked at the curr_clocksource structure and saw that the last
seen time on the kvmclock clock source was greater than the value that
the kvmclock device migrated.
> 2) What is the host clocksource.
>
> The test below is not a good one because:
>
> T1) KVM_GET_CLOCK (save s->clock).
> T2) save env->tsc.
>
> The difference in scaled time between T1 and T2 is larger than 1
> nanosecond, so the
>
> (time_at_migration > s->clock)
>
> check is almost always positive (what matters though is whether
> time backwards event can be seen reading kvmclock in the guest).
Yeah, at first I was thinking it makes sense to just not use the
KVM_GET_CLOCK value at all because it's redundant to the in-memory
values. Maybe that is the better alternative after all.
Alex
next prev parent reply other threads:[~2014-05-06 7:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 13:51 [Qemu-devel] [PATCH] kvmclock: Ensure time in migration never goes backward Alexander Graf
2014-05-05 17:46 ` Marcin Gibuła
2014-05-05 18:05 ` Alexander Graf
2014-05-05 18:26 ` Marcin Gibuła
2014-05-05 23:27 ` Marcelo Tosatti
2014-05-05 23:31 ` Marcelo Tosatti
2014-05-06 8:07 ` Marcin Gibuła
2014-05-06 7:11 ` Alexander Graf
2014-05-06 7:37 ` Marcin Gibuła
2014-05-05 23:23 ` Marcelo Tosatti
2014-05-05 23:31 ` Marcelo Tosatti
2014-05-06 7:18 ` Alexander Graf
2014-05-06 19:54 ` Marcin Gibuła
2014-05-07 23:23 ` Marcelo Tosatti
2014-05-07 23:21 ` Marcelo Tosatti
2014-05-07 23:29 ` Alexander Graf
2014-05-06 7:16 ` Alexander Graf [this message]
2014-05-07 10:04 ` Nick Thomas
2014-05-08 1:33 ` Marcelo Tosatti
2014-05-08 7:21 ` Alexander Graf
2014-05-09 2:28 ` Marcelo Tosatti
2014-05-09 11:53 ` Paolo Bonzini
2014-05-12 20:26 ` Alexander Graf
2014-05-14 7:26 ` Marcelo Tosatti
2014-05-14 6:47 ` Marcelo Tosatti
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=53688C56.6020109@suse.de \
--to=agraf@suse.de \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=nick@bytemark.co.uk \
--cc=qemu-devel@nongnu.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).