Re: Monotonic clock with KVM pv-clock

Fernando Luis Vazquez Cao
2014-01-21T14:23:55Z

(2014/01/21 9:19), Marcelo Tosatti wrote:
> On Mon, Jan 20, 2014 at 11:59:39PM +0900, Fernando Luis Vazquez Cao wrote:
>> (2014/01/20 22:33), Marcelo Tosatti wrote:
>>> On Mon, Jan 20, 2014 at 11:56:56AM +0200, Nadav Har'El wrote:
>>>> If KVM_SYSTEM_TIME is not a correct way to get a monotonic paravirtual clock
>>> >from KVM, is there a correct way?
>>> Inside a Linux guest? Can use sched_clock().
>> I would like to mention that Linux guests usually do not use sched_clock()
>> directly. The reason being that the kvm_clock based sched_clock() is not
>> marked stable (sched_clock_stable is 0), which means that the pair of
>> wrappers sched_clock_local()/sched_clock_remote() is used instead.
> Should verify the requirements of sched_clock_cpu() and enable
> sched_clock_stable in case it fulfills requirements

The requirements of cpu_clock() are (from code comments in
kernel/sched/clock.c):

1. cpu_clock(i) provides a fast (execution time) high resolution
2. Clock with bounded drift between CPUs.
3. The value of cpu_clock(i) is monotonic for constant i (when comparing
cpu_clock(i)
to cpu_clock(j) for i != j, time can go backwards)
4. The timestamp returned is in nanoseconds.

Besides, for sched_clock() to be considered stable

5. it has to be synchronized across CPUs.

> (kvmclock_read can be nondecreasing due to TSC->nanosecond scaling,

s/nondecreasing/nonincreasing/? I guess you mean that consecutive calls to
kvm_clock_read() can return the same nanosecond value when the TSC
frequency is greater than 1GHz or there are frequency changes.

> and not increase for a longer duration with global accumulator, due
> to cmpxchg)

Yes. If I understand correctly, that can happen if
PVCLOCK_TSC_STABLE_BIT is not set.

I think that when PVCLOCK_TSC_STABLE_BIT is set we should be fine as
long as backward motion is filtered out.