qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2016-11-04 21:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04  9:43 [Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save Marcelo Tosatti
2016-11-04 12:28 ` Juan Quintela
2016-11-04 12:35   ` Marcelo Tosatti
2016-11-04 14:00     ` Marcelo Tosatti
2016-11-04 15:25 ` Radim Krčmář
2016-11-04 15:33   ` Paolo Bonzini
2016-11-04 15:48     ` Radim Krčmář
2016-11-04 15:57       ` Paolo Bonzini
2016-11-04 17:16         ` Radim Krčmář
2016-11-04 21:29           ` Paolo Bonzini
2016-11-04 21:47             ` Marcelo Tosatti [this message]
2016-11-04 22:35               ` Paolo Bonzini
2016-11-07 14:31           ` Roman Kagan
2016-11-07 19:31             ` Marcelo Tosatti
2016-11-04 16:24       ` Marcelo Tosatti
2016-11-04 17:34         ` Radim Krčmář
2016-11-04 18:29           ` Marcelo Tosatti
2016-11-04 20:07             ` Radim Krčmář
2016-11-04 16:04   ` Marcelo Tosatti
2016-11-04 17:07   ` Marcelo Tosatti
2016-11-04 17:39     ` Radim Krčmář
2016-11-04 18:31       ` Marcelo Tosatti
2016-11-07 13:08       ` Dr. David Alan Gilbert
2016-11-04 16:59 ` [Qemu-devel] [QEMU PATCH v2] " Marcelo Tosatti
2016-11-04 18:57   ` Juan Quintela
2016-11-07 15:46   ` Dr. David Alan Gilbert
2016-11-07 19:41     ` Marcelo Tosatti
2016-11-07 20:03       ` Dr. David Alan Gilbert
2016-11-08  0:06         ` Marcelo Tosatti
2016-11-08 10:22           ` Dr. David Alan Gilbert
2016-11-08 13:32             ` Marcelo Tosatti
2016-11-09 19:32               ` Marcelo Tosatti
2016-11-09 16:23             ` Paolo Bonzini
2016-11-09 16:28               ` Dr. David Alan Gilbert
2016-11-09 16:33                 ` Paolo Bonzini
2016-11-10 11:48               ` Marcelo Tosatti
2016-11-10 17:57                 ` Paolo Bonzini
2016-11-11 14:23                   ` Marcelo Tosatti
2017-02-07 10:02       ` Wanpeng Li
2017-02-07 12:18         ` 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 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).