aboutsummaryrefslogtreecommitdiffstats
path: root/virt/kvm/kvm_main.c
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2020-01-22 14:36:09 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2020-02-05 15:17:45 +0100
commit8171cd68806bd2fc28ef688e32fb2a3b3deb04e5 (patch)
tree75d54e672f19cf645c01889b524f9865853f383a /virt/kvm/kvm_main.c
parentKVM: x86: reorganize pvclock_gtod_data members (diff)
downloadlinux-dev-8171cd68806bd2fc28ef688e32fb2a3b3deb04e5.tar.xz
linux-dev-8171cd68806bd2fc28ef688e32fb2a3b3deb04e5.zip
KVM: x86: use raw clock values consistently
Commit 53fafdbb8b21f ("KVM: x86: switch KVMCLOCK base to monotonic raw clock") changed kvmclock to use tkr_raw instead of tkr_mono. However, the default kvmclock_offset for the VM was still based on the monotonic clock and, if the raw clock drifted enough from the monotonic clock, this could cause a negative system_time to be written to the guest's struct pvclock. RHEL5 does not like it and (if it boots fast enough to observe a negative time value) it hangs. There is another thing to be careful about: getboottime64 returns the host boot time with tkr_mono frequency, and subtracting the tkr_raw-based kvmclock value will cause the wallclock to be off if tkr_raw drifts from tkr_mono. To avoid this, compute the wallclock delta from the current time instead of being clever and using getboottime64. Fixes: 53fafdbb8b21f ("KVM: x86: switch KVMCLOCK base to monotonic raw clock") Cc: stable@vger.kernel.org Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'virt/kvm/kvm_main.c')
0 files changed, 0 insertions, 0 deletions