[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161109211404.GA2218@amt.cnet>
Date: Wed, 9 Nov 2016 19:14:07 -0200
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH] kvm: kvmclock: let KVM_GET_CLOCK return whether the
master clock is in use
On Wed, Nov 09, 2016 at 06:17:16PM -0200, Marcelo Tosatti wrote:
> On Wed, Nov 09, 2016 at 06:12:50PM -0200, Marcelo Tosatti wrote:
> > On Wed, Nov 09, 2016 at 05:48:15PM +0100, Paolo Bonzini wrote:
> > > Userspace can read the exact value of kvmclock by reading the TSC
> > > and fetching the timekeeping parameters out of guest memory. This
> > > however is brittle and not necessary anymore with KVM 4.11.
> >
> > Hi Paolo,
> >
> > Can you point to commit or explanation why that is not the case anymore?
> > Thanks
>
> I don't see how thats possible given the:
>
> * TSC
> * TSC (timer interrupt + TSC deltas) (AKA host TSC clocksource and
> * CLOCK_MONOTONIC).
>
> Clocks currently drift from each other (therefore are not monotonic).
>
> Have you confirmed CLOCK_MONOTONIC_RAW and TSC are monotonic?
I think the benefits of CLOCK_MONOTONIC_RAW (which supposedly
is monotonic with TSC for large lenghts of time) outweight the
downsides (just have to check that).
The downsides are that on migration from
source: TSC with freq Y.
dest: TSC with freq X.
Suddenly kvmclock starts drifting at a different rate,
unsure how well Windows time service and
older NTPd respond to this (might be a regression).
Powered by blists - more mailing lists