(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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
