From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: What time is it kvm-clock?
Date: Thu, 25 Feb 2016 12:13:29 +0100
Message-ID: <20160225111328.GA18319@potion.redhat.com>
References: <CANqFzA5VCQYZ6dYBjz=hbBotwe0S_4cKgxGiK9YU8Ei9G7DYng@mail.gmail.com>
 <20160224035753.GA6681@amt.cnet>
 <CA+0KQ4PXW90DWw3nkonbvGY5aiYLi4Vg-aYWt5s_q1MXpRKMzA@mail.gmail.com>
 <20160224201757.GA6355@potion.redhat.com>
 <CALCETrVJuZtqQ2OEv-TcCbgZhWFh11XTJ3cQEqsQUKSsBVHA7Q@mail.gmail.com>
 <20160224205323.GB6355@potion.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Peter Hornyack <peterhornyack@google.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Owen Hofmann <osh@google.com>,
	KVM General <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:43441 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752706AbcBYLNd (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 25 Feb 2016 06:13:33 -0500
Content-Disposition: inline
In-Reply-To: <20160224205323.GB6355@potion.redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2016-02-24 21:53+0100, Radim Kr=C4=8Dm=C3=A1=C5=99:
> 2016-02-24 12:24-0800, Andy Lutomirski:
>> On Wed, Feb 24, 2016 at 12:17 PM, Radim Kr=C4=8Dm=C3=A1=C5=99 <rkrcm=
ar@redhat.com> wrote:
>>> Do you find anything incorrect with
>>>  * kvmclock measures the flow of time.
>>>  * time in kvmclock flows at the same rate as host's CLOCK_BOOTTIME=
=2E
>>> ?
>>=20
>> If we could supply CLOCK_REALTIME as well and advertise that fact to
>> guest userspace (perhaps with a sysctl or similar in the guest to tu=
rn
>> it on), it would be *awesome*.  Guests with access to this feature
>> could simply not run ntpd/chronyd.
>=20
> I think that pvclock_wall_clock interface is there to do that.
> (If pvclock_vcpu_time_info can provide what is claimed above.)
>=20
> If pvclock_wall_clock version field matches with pvclock_vcpu_time_in=
fo,

Correction: versioning schemes are independent.  (pvclock_wall_clock
needs a version because of CPUs that can't atomically access 64 bits.)

> then the guest can add those two and get CLOCK_REALTIME.

pvclock_wall_clock provides CLOCK_REALTIME when pvclock_wall_clock was
0, so the guest can just add them to get current CLOCK_REALTIME.

(The agreement is that CLOCK_REALTIME started in 1970.)