From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Kagan Subject: Re: [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save Date: Mon, 7 Nov 2016 17:31:49 +0300 Message-ID: <20161107143148.GA2199@rkaganb.sw.ru> References: <20161104094322.GA16930@amt.cnet> <20161104152522.GC5388@potion> <1c69a083-eef0-8fa0-0e74-5a4e25a066a0@redhat.com> <20161104154827.GD5388@potion> <1217f6ce-8143-8d0e-97f6-470926438992@redhat.com> <20161104171605.GE5388@potion> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: Eduardo Habkost , kvm@vger.kernel.org, Juan Quintela , Marcelo Tosatti , qemu-devel , "Dr. David Alan Gilbert" , Paolo Bonzini To: Radim =?utf-8?B?S3LEjW3DocWZ?= Return-path: Content-Disposition: inline In-Reply-To: <20161104171605.GE5388@potion> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On Fri, Nov 04, 2016 at 06:16:06PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote= : > 2016-11-04 16:57+0100, Paolo Bonzini: > > On 04/11/2016 16:48, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > >> 2016-11-04 16:33+0100, Paolo Bonzini: > >>> On 04/11/2016 16:25, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > >>>>>> =20 > >>>>>> + if (s->advance_clock && s->clock + s->advance_clock > s->= clock) { > >>>>>> + s->clock +=3D s->advance_clock; > >>>>>> + s->advance_clock =3D 0; > >>>>>> + } > >>>> Can't the advance_clock added to the migrated KVMClockState instead = of > >>>> passing it as another parameter? > >>>> > >>>> (It is sad that we can't just query KVMClockState in kvmclock_pre_sa= ve > >>>> because of the Linux bug.) > >>> > >>> What Linux bug? The one that makes us use kvmclock_current_nsec? > >>=20 > >> 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"). > >=20 > > There are two cases: > >=20 > > - migrating a paused guest > >=20 > > - pausing at the end of migration > >=20 > > In the first case, kvmclock_vm_state_change's !running branch will see > > state =3D=3D RUN_STATE_FINISH_MIGRATE && s->clock_valid. In the second > > case, it will see state =3D=3D RUN_STATE_FINISH_MIGRATE && !s->clock_va= lid. >=20 > I lift my case, marcelo's said that stopping the time is a feature ... > (*kittens die*) Sorry to chime in in the middle of the thread, but I wonder how happy the guests are with this behavior. Intuitively pausing or snapshotting feels like closing the lid of a laptop, so every time I see the guest waking up in the past after a pause I get confused. It may also be unexpected by Windows guests who never had this overflow problem but now, being tied up with kvmclock, have to stop the time while in pause, too. Roman. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3mc9-0002jQ-Ch for qemu-devel@nongnu.org; Mon, 07 Nov 2016 11:17:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3mc4-0001nL-3N for qemu-devel@nongnu.org; Mon, 07 Nov 2016 11:17:41 -0500 Received: from mail-he1eur01hn0205.outbound.protection.outlook.com ([104.47.0.205]:8732 helo=EUR01-HE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c3mc3-0001mu-F1 for qemu-devel@nongnu.org; Mon, 07 Nov 2016 11:17:36 -0500 Date: Mon, 7 Nov 2016 17:31:49 +0300 From: Roman Kagan Message-ID: <20161107143148.GA2199@rkaganb.sw.ru> References: <20161104094322.GA16930@amt.cnet> <20161104152522.GC5388@potion> <1c69a083-eef0-8fa0-0e74-5a4e25a066a0@redhat.com> <20161104154827.GD5388@potion> <1217f6ce-8143-8d0e-97f6-470926438992@redhat.com> <20161104171605.GE5388@potion> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20161104171605.GE5388@potion> Subject: Re: [Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: Paolo Bonzini , Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel , "Dr. David Alan Gilbert" , Juan Quintela , Eduardo Habkost On Fri, Nov 04, 2016 at 06:16:06PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote= : > 2016-11-04 16:57+0100, Paolo Bonzini: > > On 04/11/2016 16:48, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > >> 2016-11-04 16:33+0100, Paolo Bonzini: > >>> On 04/11/2016 16:25, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > >>>>>> =20 > >>>>>> + if (s->advance_clock && s->clock + s->advance_clock > s->= clock) { > >>>>>> + s->clock +=3D s->advance_clock; > >>>>>> + s->advance_clock =3D 0; > >>>>>> + } > >>>> Can't the advance_clock added to the migrated KVMClockState instead = of > >>>> passing it as another parameter? > >>>> > >>>> (It is sad that we can't just query KVMClockState in kvmclock_pre_sa= ve > >>>> because of the Linux bug.) > >>> > >>> What Linux bug? The one that makes us use kvmclock_current_nsec? > >>=20 > >> 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"). > >=20 > > There are two cases: > >=20 > > - migrating a paused guest > >=20 > > - pausing at the end of migration > >=20 > > In the first case, kvmclock_vm_state_change's !running branch will see > > state =3D=3D RUN_STATE_FINISH_MIGRATE && s->clock_valid. In the second > > case, it will see state =3D=3D RUN_STATE_FINISH_MIGRATE && !s->clock_va= lid. >=20 > I lift my case, marcelo's said that stopping the time is a feature ... > (*kittens die*) Sorry to chime in in the middle of the thread, but I wonder how happy the guests are with this behavior. Intuitively pausing or snapshotting feels like closing the lid of a laptop, so every time I see the guest waking up in the past after a pause I get confused. It may also be unexpected by Windows guests who never had this overflow problem but now, being tied up with kvmclock, have to stop the time while in pause, too. Roman.