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 13:20:53 +0100 Message-ID: <20160225122053.GC18319@potion.redhat.com> References: <20160224035753.GA6681@amt.cnet> <20160224233500.GA17304@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andy Lutomirski , Marcelo Tosatti , Peter Hornyack , KVM General , Paolo Bonzini To: Owen Hofmann Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36001 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760605AbcBYMU5 (ORCPT ); Thu, 25 Feb 2016 07:20:57 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-02-24 19:50-0800, Owen Hofmann: > On Wed, Feb 24, 2016 at 5:19 PM, Andy Lutomirski wrote: >> 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. >> >> 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. > > Your proposal, which I'd describe as a direct passthrough (to the > extent possible) of the host gettimeofday vdso to a kvm guest, sounds > like a much better way to get clock frequency adjustments from the > host to the guest. But I don't know if I can think of a reason to do > this besides "hey you don't have to run ntp". Is there a situation you > have in mind that this helps out? Running NTP only on the host is a good reason. (And probably the only reason I'd call good, because any software that passes TSC or CLOCK_MONOTONIC timestamps between hosts needs to handle their differences.) I'd prefer to avoid direct access to host's TSC or CLOCK_MONOTONIC from the guest, so migrations aren't more complicated than they are now. Passing host's CLOCK_REALTIME to the guest (which can be done with pvclock) is enough for any isolated application. (considering that guest's pvclock ticks at expected rate, which is host's job.) But need paravirtual interface(s) to precisely sync host and guest CLOCK_REALTIME even on machines with VMX TSC offset and scaling, so Is the the pvclock interface is unable to fulfill our goals? Do you want to simplify or extend the pvclock interface?