Re: What time is it kvm-clock?

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Feb 24, 2016 at 09:53:23PM +0100, Radim Krčmář wrote:
> 2016-02-24 12:24-0800, Andy Lutomirski:
> > On Wed, Feb 24, 2016 at 12:17 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> >> 2016-02-24 09:35-0800, Peter Hornyack:
> >>> On Tue, Feb 23, 2016 at 7:57 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >>>> On Tue, Feb 23, 2016 at 06:31:59PM -0800, Owen Hofmann wrote:
> >>>>> Regardless of my opinion, I think that a clear statement of the design
> >>>>> goals for kvm-clock (and kvm's implementation of the reference TSC
> >>>>> page) would be valuable.
> >>>>
> >>>> Documentation/virtual/kvm/timekeeping.txt
> >>>>
> >>>
> >>> Hi Marcelo,
> >>>
> >>> While I appreciate all of the detail in timekeeping.txt, it is not a
> >>> very good reference for what kvm-clock is or how it works. kvm-clock
> >>> is only mentioned three times in different places throughout that
> >>> document, and nowhere is there a very clear statement of what
> >>> kvm-clock is supposed to do or how it does it.
> >>>
> >>> For somebody that does not already have a deep understanding of the
> >>> core masterclock code, trying to understand how kvm-clock works is a
> >>> real challenge.
> >>
> >> I agree.  Having an overview would be very helpful.
> >>
> >> 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.
> >> ?
> > 
> > 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 turn
> > it on), it would be *awesome*.  Guests with access to this feature
> > could simply not run ntpd/chronyd.
> 
> I think that pvclock_wall_clock interface is there to do that.
> (If pvclock_vcpu_time_info can provide what is claimed above.)
> 
> If pvclock_wall_clock version field matches with pvclock_vcpu_time_info,
> then the guest can add those two and get CLOCK_REALTIME.
> (Based on observations of angry users, the implementation lacking.)
> 
> >> Maybe it would be better to say "best estimate of real time" instead of
> >> "CLOCK_BOOTTIME", so people wouldn't jump to conclusion that
> >> CLOCK_BOOTTIME has something to do with kvmclock ...
> > 
> > We still need to define what zero means, if anything.
> 
> I think it's better if only the difference between two reads has a
> meaning (the number of nanoseconds that passed).  Zero is then an
> arbitrary value.
> 
> (If we're talking about system_time.)
> 
> >> Then we could mention migration (why the time becomes imprecise) and
> >> finish by explaining the TSC mechanism (that avoids a vmexit on every
> >> read) and advantages of masterclock.
> > 
> > We should also explain what masterclock is, aside from being an
> > implementation detail.  I've read the code and I still don't know.
> 
> Yeah, rewriting the code would be a good deed.

Please do so.