summaryrefslogtreecommitdiff
path: root/virt/lib/irqbypass.c
diff options
context:
space:
mode:
authorRadim Krčmář <rkrcmar@redhat.com>2015-09-18 18:54:29 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2015-10-01 16:06:42 +0300
commit72c930dcfc2b49404ee9e20f6c868402e9c71166 (patch)
tree83ff98a7c359fef9f294bbca18529bca8caf7a27 /virt/lib/irqbypass.c
parent1cea0ce68ed76490ffa64a9e2a7a40104efe9352 (diff)
downloadlinux-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