From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
kvm@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Roman Kagan" <rkagan@virtuozzo.com>
Subject: Re: [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save
Date: Fri, 4 Nov 2016 19:47:47 -0200 [thread overview]
Message-ID: <20161104214747.GA17560@amt.cnet> (raw)
In-Reply-To: <595276440.10962400.1478294976364.JavaMail.zimbra@redhat.com>
On Fri, Nov 04, 2016 at 05:29:36PM -0400, Paolo Bonzini wrote:
>
> > >> No, the one that forced Marcelo to add the 10 minute limit to the
> > >> advance_clock. We wouldn't need this advance_clock hack if we could
> > >> just call KVM_GET_CLOCK like we did before 00f4d64ee76e ("kvmclock:
> > >> clock should count only if vm is running").
> > >
> > > There are two cases:
> > >
> > > - migrating a paused guest
> > >
> > > - pausing at the end of migration
> > >
> > > In the first case, kvmclock_vm_state_change's !running branch will see
> > > state == RUN_STATE_FINISH_MIGRATE && s->clock_valid. In the second
> > > case, it will see state == RUN_STATE_FINISH_MIGRATE && !s->clock_valid.
> >
> > I lift my case, marcelo's said that stopping the time is a feature ...
> > (*kittens die*)
>
> But that's why separating the two cases brings us the best of both worlds.
> If migrating a paused guest, there's no need for any adjustment, so no
> advance_clock hack. If pausing at the end of migration, there's no need
> to pause kvmclock (this patch is effectively working around 00f4d64ee76e)
> and if we don't do that we can just call KVM_GET_CLOCK at pre_save time.
That was my internal v1. But then, the destination ignores s->clock
as follows:
if (running) {
struct kvm_clock_data data = {};
uint64_t time_at_migration = kvmclock_current_nsec(s);
s->clock_valid = false;
/* We can't rely on the migrated clock value, just discard it */
if (time_at_migration) {
s->clock = time_at_migration;
}
data.clock = s->clock;
ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
So you need to send that "ns" value (difference of two clock reads)
separately.
>
> > Oh, and this does introduce a minor bug to this patch -- the time
> > counted by KVM_GET_CLOCK is has different frequency CLOCK_MONOTONIC.
> > Not accounting for that is bearable.
>
> Not really, I was going to point that out when I got to replying with
> a review. :)
>
> Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
kvm@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Roman Kagan" <rkagan@virtuozzo.com>
Subject: Re: [Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save
Date: Fri, 4 Nov 2016 19:47:47 -0200 [thread overview]
Message-ID: <20161104214747.GA17560@amt.cnet> (raw)
In-Reply-To: <595276440.10962400.1478294976364.JavaMail.zimbra@redhat.com>
On Fri, Nov 04, 2016 at 05:29:36PM -0400, Paolo Bonzini wrote:
>
> > >> No, the one that forced Marcelo to add the 10 minute limit to the
> > >> advance_clock. We wouldn't need this advance_clock hack if we could
> > >> just call KVM_GET_CLOCK like we did before 00f4d64ee76e ("kvmclock:
> > >> clock should count only if vm is running").
> > >
> > > There are two cases:
> > >
> > > - migrating a paused guest
> > >
> > > - pausing at the end of migration
> > >
> > > In the first case, kvmclock_vm_state_change's !running branch will see
> > > state == RUN_STATE_FINISH_MIGRATE && s->clock_valid. In the second
> > > case, it will see state == RUN_STATE_FINISH_MIGRATE && !s->clock_valid.
> >
> > I lift my case, marcelo's said that stopping the time is a feature ...
> > (*kittens die*)
>
> But that's why separating the two cases brings us the best of both worlds.
> If migrating a paused guest, there's no need for any adjustment, so no
> advance_clock hack. If pausing at the end of migration, there's no need
> to pause kvmclock (this patch is effectively working around 00f4d64ee76e)
> and if we don't do that we can just call KVM_GET_CLOCK at pre_save time.
That was my internal v1. But then, the destination ignores s->clock
as follows:
if (running) {
struct kvm_clock_data data = {};
uint64_t time_at_migration = kvmclock_current_nsec(s);
s->clock_valid = false;
/* We can't rely on the migrated clock value, just discard it */
if (time_at_migration) {
s->clock = time_at_migration;
}
data.clock = s->clock;
ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
So you need to send that "ns" value (difference of two clock reads)
separately.
>
> > Oh, and this does introduce a minor bug to this patch -- the time
> > counted by KVM_GET_CLOCK is has different frequency CLOCK_MONOTONIC.
> > Not accounting for that is bearable.
>
> Not really, I was going to point that out when I got to replying with
> a review. :)
>
> Paolo
next prev parent reply other threads:[~2016-11-04 21:48 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 9:43 [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save Marcelo Tosatti
2016-11-04 9:43 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 12:28 ` Juan Quintela
2016-11-04 12:28 ` [Qemu-devel] " Juan Quintela
2016-11-04 12:35 ` Marcelo Tosatti
2016-11-04 12:35 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 14:00 ` Marcelo Tosatti
2016-11-04 14:00 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 15:25 ` Radim Krčmář
2016-11-04 15:25 ` [Qemu-devel] " Radim Krčmář
2016-11-04 15:33 ` Paolo Bonzini
2016-11-04 15:33 ` [Qemu-devel] " Paolo Bonzini
2016-11-04 15:48 ` Radim Krčmář
2016-11-04 15:48 ` [Qemu-devel] " Radim Krčmář
2016-11-04 15:57 ` Paolo Bonzini
2016-11-04 15:57 ` [Qemu-devel] " Paolo Bonzini
2016-11-04 17:16 ` Radim Krčmář
2016-11-04 17:16 ` [Qemu-devel] " Radim Krčmář
2016-11-04 21:29 ` Paolo Bonzini
2016-11-04 21:29 ` [Qemu-devel] " Paolo Bonzini
2016-11-04 21:47 ` Marcelo Tosatti [this message]
2016-11-04 21:47 ` Marcelo Tosatti
2016-11-04 22:35 ` Paolo Bonzini
2016-11-04 22:35 ` [Qemu-devel] " Paolo Bonzini
2016-11-07 14:31 ` Roman Kagan
2016-11-07 14:31 ` [Qemu-devel] " Roman Kagan
2016-11-07 19:31 ` Marcelo Tosatti
2016-11-07 19:31 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 16:24 ` Marcelo Tosatti
2016-11-04 16:24 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 17:34 ` Radim Krčmář
2016-11-04 17:34 ` [Qemu-devel] " Radim Krčmář
2016-11-04 18:29 ` Marcelo Tosatti
2016-11-04 18:29 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 20:07 ` Radim Krčmář
2016-11-04 20:07 ` [Qemu-devel] " Radim Krčmář
2016-11-04 16:04 ` Marcelo Tosatti
2016-11-04 16:04 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 17:07 ` Marcelo Tosatti
2016-11-04 17:07 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 17:39 ` Radim Krčmář
2016-11-04 17:39 ` [Qemu-devel] " Radim Krčmář
2016-11-04 18:31 ` Marcelo Tosatti
2016-11-04 18:31 ` [Qemu-devel] " Marcelo Tosatti
2016-11-07 13:08 ` Dr. David Alan Gilbert
2016-11-07 13:08 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-11-04 16:59 ` [QEMU PATCH v2] " Marcelo Tosatti
2016-11-04 16:59 ` [Qemu-devel] " Marcelo Tosatti
2016-11-04 18:57 ` Juan Quintela
2016-11-04 18:57 ` [Qemu-devel] " Juan Quintela
2016-11-07 15:46 ` Dr. David Alan Gilbert
2016-11-07 15:46 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-11-07 19:41 ` Marcelo Tosatti
2016-11-07 19:41 ` [Qemu-devel] " Marcelo Tosatti
2016-11-07 20:03 ` Dr. David Alan Gilbert
2016-11-07 20:03 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-11-08 0:06 ` Marcelo Tosatti
2016-11-08 0:06 ` [Qemu-devel] " Marcelo Tosatti
2016-11-08 10:22 ` Dr. David Alan Gilbert
2016-11-08 10:22 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-11-08 13:32 ` Marcelo Tosatti
2016-11-08 13:32 ` [Qemu-devel] " Marcelo Tosatti
2016-11-09 19:32 ` Marcelo Tosatti
2016-11-09 19:32 ` [Qemu-devel] " Marcelo Tosatti
2016-11-09 16:23 ` Paolo Bonzini
2016-11-09 16:23 ` [Qemu-devel] " Paolo Bonzini
2016-11-09 16:28 ` Dr. David Alan Gilbert
2016-11-09 16:28 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-11-09 16:33 ` Paolo Bonzini
2016-11-09 16:33 ` [Qemu-devel] " Paolo Bonzini
2016-11-10 11:48 ` Marcelo Tosatti
2016-11-10 11:48 ` [Qemu-devel] " Marcelo Tosatti
2016-11-10 17:57 ` Paolo Bonzini
2016-11-10 17:57 ` [Qemu-devel] " Paolo Bonzini
2016-11-11 14:23 ` Marcelo Tosatti
2016-11-11 14:23 ` [Qemu-devel] " Marcelo Tosatti
2017-02-07 10:02 ` Wanpeng Li
2017-02-07 10:02 ` [Qemu-devel] " Wanpeng Li
2017-02-07 12:18 ` Marcelo Tosatti
2017-02-07 12:18 ` [Qemu-devel] " 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=20161104214747.GA17560@amt.cnet \
--to=mtosatti@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rkagan@virtuozzo.com \
--cc=rkrcmar@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.