From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration Date: Mon, 28 Nov 2016 16:12:55 +0100 Message-ID: <44a6702d-e91e-2815-1e2e-aef67d750b9e@redhat.com> References: <62d634ab-70ad-4be7-1622-f2e3a9d865fe@redhat.com> <20161114145054.GA28663@amt.cnet> <67bffd95-2e4e-7273-c154-a3fdfe622387@redhat.com> <20161114154015.GA30048@amt.cnet> <20161114171318.GA6336@amt.cnet> <14044cda-054d-94eb-8d91-7ad3a1e0869e@redhat.com> <20161114181518.GA14076@amt.cnet> <20161117121637.GA13404@amt.cnet> <1023a283-77a7-45e5-8877-6264e08d0658@redhat.com> <20161128142855.GC14328@thinpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Juan Quintela , Radim Krcmar To: Eduardo Habkost Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:33051 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933158AbcK1PM7 (ORCPT ); Mon, 28 Nov 2016 10:12:59 -0500 Received: by mail-wm0-f67.google.com with SMTP id u144so19465563wmu.0 for ; Mon, 28 Nov 2016 07:12:58 -0800 (PST) In-Reply-To: <20161128142855.GC14328@thinpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: On 28/11/2016 15:28, Eduardo Habkost wrote: > > + s->src_use_reliable_get_clock = data.flags & KVM_CLOCK_TSC_STABLE; > > I still don't understand the reasoning behind > kvm_has_adjust_clock_stable() vs (flags & KVM_CLOCK_TSC_STABLE), > but on either case, updating src_use_reliable_get_clock inside > kvm_get_clock() looks like the right thing to do. There are three possibility: the kernel tells you the clock is stable, the kernel tells you the clock is unstable, the kernel is too old and doesn't tell you anything. Then: kvm_has_adjust_clock_stable() == true: if the clock is stable, KVM_CLOCK_TSC_STABLE will be set in "flags" if the clock is unstable, KVM_CLOCK_TSC_STABLE will be unset kvm_has_adjust_clock_stable() == false: you cannot know if the clock is stable Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBNd4-00026N-4Y for qemu-devel@nongnu.org; Mon, 28 Nov 2016 10:14:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBNd0-0008G7-UF for qemu-devel@nongnu.org; Mon, 28 Nov 2016 10:14:02 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34329) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBNd0-0008Fc-E1 for qemu-devel@nongnu.org; Mon, 28 Nov 2016 10:13:58 -0500 Received: by mail-wm0-f67.google.com with SMTP id g23so19549693wme.1 for ; Mon, 28 Nov 2016 07:13:58 -0800 (PST) Sender: Paolo Bonzini References: <62d634ab-70ad-4be7-1622-f2e3a9d865fe@redhat.com> <20161114145054.GA28663@amt.cnet> <67bffd95-2e4e-7273-c154-a3fdfe622387@redhat.com> <20161114154015.GA30048@amt.cnet> <20161114171318.GA6336@amt.cnet> <14044cda-054d-94eb-8d91-7ad3a1e0869e@redhat.com> <20161114181518.GA14076@amt.cnet> <20161117121637.GA13404@amt.cnet> <1023a283-77a7-45e5-8877-6264e08d0658@redhat.com> <20161128142855.GC14328@thinpad.lan.raisama.net> From: Paolo Bonzini Message-ID: <44a6702d-e91e-2815-1e2e-aef67d750b9e@redhat.com> Date: Mon, 28 Nov 2016 16:12:55 +0100 MIME-Version: 1.0 In-Reply-To: <20161128142855.GC14328@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Juan Quintela , Radim Krcmar On 28/11/2016 15:28, Eduardo Habkost wrote: > > + s->src_use_reliable_get_clock = data.flags & KVM_CLOCK_TSC_STABLE; > > I still don't understand the reasoning behind > kvm_has_adjust_clock_stable() vs (flags & KVM_CLOCK_TSC_STABLE), > but on either case, updating src_use_reliable_get_clock inside > kvm_get_clock() looks like the right thing to do. There are three possibility: the kernel tells you the clock is stable, the kernel tells you the clock is unstable, the kernel is too old and doesn't tell you anything. Then: kvm_has_adjust_clock_stable() == true: if the clock is stable, KVM_CLOCK_TSC_STABLE will be set in "flags" if the clock is unstable, KVM_CLOCK_TSC_STABLE will be unset kvm_has_adjust_clock_stable() == false: you cannot know if the clock is stable Paolo