diff options
author | Radim Krčmář <rkrcmar@redhat.com> | 2015-09-18 18:54:29 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2015-10-01 16:06:42 +0300 |
commit | 72c930dcfc2b49404ee9e20f6c868402e9c71166 (patch) | |
tree | 83ff98a7c359fef9f294bbca18529bca8caf7a27 /virt/lib/irqbypass.c | |
parent | 1cea0ce68ed76490ffa64a9e2a7a40104efe9352 (diff) | |
download | linux-72c930dcfc2b49404ee9e20f6c868402e9c71166.tar.xz |
x86: kvmclock: abolish PVCLOCK_COUNTS_FROM_ZERO
Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore.
The purpose of that flags was to start counting system time from 0 when
the KVM clock has been initialized.
We can achieve the same by selecting one read as the initial point.
A simple subtraction will work unless the KVM clock count overflows
earlier (has smaller width) than scheduler's cycle count. We should be
safe till x86_128.
Because PVCLOCK_COUNTS_FROM_ZERO was enabled only on new hypervisors,
setting sched clock as stable based on PVCLOCK_TSC_STABLE_BIT might
regress on older ones.
I presume we don't need to change kvm_clock_read instead of introducing
kvm_sched_clock_read. A problem could arise in case sched_clock is
expected to return the same value as get_cycles, but we should have
merged those clocks in that case.
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Acked-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'virt/lib/irqbypass.c')
0 files changed, 0 insertions, 0 deletions