public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Peter Hornyack <peterhornyack@google.com>,
	Owen Hofmann <osh@google.com>, KVM General <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: What time is it kvm-clock?
Date: Thu, 25 Feb 2016 12:36:12 +0100	[thread overview]
Message-ID: <20160225113611.GB18319@potion.redhat.com> (raw)
In-Reply-To: <CALCETrU708tVWmX4nb7+XBcPELEuKcqd2oLvk2R0RzXL7Sb=5Q@mail.gmail.com>

2016-02-24 17:19-0800, Andy Lutomirski:
> On Wed, Feb 24, 2016 at 3:35 PM, Marcelo Tosatti <mtosatti@redhat.com> 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.

  parent reply	other threads:[~2016-02-25 11:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  2:31 What time is it kvm-clock? Owen Hofmann
2016-02-24  3:57 ` Marcelo Tosatti
2016-02-24 17:35   ` Peter Hornyack
2016-02-24 20:17     ` Radim Krčmář
2016-02-24 20:24       ` Andy Lutomirski
2016-02-24 20:53         ` Radim Krčmář
2016-02-25 11:13           ` Radim Krčmář
2016-02-25 11:22           ` Marcelo Tosatti
2016-02-24 23:35     ` Marcelo Tosatti
2016-02-24 23:36       ` Marcelo Tosatti
2016-02-25  1:19       ` Andy Lutomirski
2016-02-25  3:50         ` Owen Hofmann
2016-02-25 12:20           ` Radim Krčmář
2016-02-26 17:02             ` Andy Lutomirski
2016-02-26 19:30               ` Marcelo Tosatti
2016-02-27  0:00                 ` Andy Lutomirski
2016-02-25 11:36         ` Radim Krčmář [this message]
2016-02-25 12:12         ` Marcelo Tosatti
2016-02-24  3:59 ` Marcelo Tosatti
2016-02-24 14:14 ` Paolo Bonzini
2016-02-24 16:44   ` Andy Lutomirski
2016-02-24 17:38     ` Marcelo Tosatti
2016-02-24 19:38       ` Andy Lutomirski
2016-02-24 19:44         ` Paolo Bonzini
2016-02-24 19:52           ` Andy Lutomirski
2016-02-24 19:55         ` Owen Hofmann
2016-02-25 12:22           ` Joao Martins
2016-02-26 15:04 ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160225113611.GB18319@potion.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mtosatti@redhat.com \
    --cc=osh@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterhornyack@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox