From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: What time is it kvm-clock? Date: Thu, 25 Feb 2016 12:36:12 +0100 Message-ID: <20160225113611.GB18319@potion.redhat.com> References: <20160224035753.GA6681@amt.cnet> <20160224233500.GA17304@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , Peter Hornyack , Owen Hofmann , KVM General , Paolo Bonzini To: Andy Lutomirski Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48418 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759156AbcBYLgQ (ORCPT ); Thu, 25 Feb 2016 06:36:16 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-02-24 17:19-0800, Andy Lutomirski: > On Wed, Feb 24, 2016 at 3:35 PM, Marcelo Tosatti wrote: >> About complaint that "its not well designed whether NTP correction >> should be applied or not". There are two different things: >> >> 1) Host clock and guest clocks synchronized. >> KVM is not responsible for that, and it can't, because >> Linux exposes a clock which is created in software >> and fixed by NTP. > > I don't understand what you mean. > > Of course the guest can run its own NTP daemon or similar adjtimex > caller and cause the guest to stop tracking the host. But if the host > passed CLOCK_MONOTONIC through, then the guest would, by default, > treat kvm-clock as an exactly 1GHz source and would then expose a > disciplined NTP-tracking CLOCK_MONOTONIC through to its user apps even > without an NTP client on the guest. kvmclock always is a 1 GHz clock, it just wasn't (maybe still isn't) a good source of source of 1 GHz. The guest can't know that it's poor unless it compares with better 1 GHz sources, for example via NTP. KVM can't know what 1 GHz is better than the host and vice-versa, so kvmclock should "accidentally" track CLOCK_BOOTTIME. But that is related to (2), I think that (1) was mainly about the offset from CLOCK_REALTIME. > If integration with the POSIX clock core were provided, the guest > would learn to consume the host's CLOCK_REALTIME as well, as long as > the host uses the tsc as its clocksource. Using TSC in the host allows KVM to provide precise CLOCK_REALTIME, but nothing prevents us from giving host's CLOCK_REALTIME even if the host is using hpet/... as the source. >> 2) NTP frequency correction being applied to kvmclock. >> >> This only means that the frequency of the pvclock reads >> in the guest are NTP corrected. > > If the host applied NTP frequency correction to the guest, then I > would be happy. Some folks might want this to be optional. kvmclock provides time in nanoseconds, so I'd argue that NTP corrections are mandatory.