[PATCH 1/2] KVM: x86: hyper-v: Forbid unsigned hv_clock->system_time to go negative after KVM_REQ_CLOCK_UPDATE

[Vitaly Kuznetsov <vkuznets@redhat.com>]

When guest time is reset with KVM_SET_CLOCK(0), it is possible for
hv_clock->system_time to become a small negative number. This happens
because in KVM_SET_CLOCK handling we set kvm->arch.kvmclock_offset based
on get_kvmclock_ns(kvm) but when KVM_REQ_CLOCK_UPDATE is handled,
kvm_guest_time_update() does

hv_clock.system_time = ka->master_kernel_ns + v->kvm->arch.kvmclock_offset;

And 'master_kernel_ns' represents the last time when masterclock
got updated, it can precede KVM_SET_CLOCK() call. Normally, this is not a
problem, the difference is very small, e.g. I'm observing
hv_clock.system_time = -70 ns. The issue comes from the fact that
'hv_clock.system_time' is stored as unsigned and 'system_time / 100' in
compute_tsc_page_parameters() becomes a very big number.

Forbid 'hv_clock.system_time' to go negative in kvm_guest_time_update().
A similar computation in get_kvmclock_ns() seems fine and doesn't require
the quirk.

Alternatively, we could've used 'master_kernel_ns' when computing
'arch.kvmclock_offset' but that would reduce the precision for normal
cases a bit. Another solution is to cast 'hv_clock.system_time' to
's64' in compute_tsc_page_parameters() but it seems we also use
'hv_clock.system_time' in trace_kvm_pvclock_update() as unsigned.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 arch/x86/kvm/x86.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fe806e894212..320da7912375 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2742,7 +2742,15 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
 	}
 
 	vcpu->hv_clock.tsc_timestamp = tsc_timestamp;
-	vcpu->hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
+
+	/*
+	 * 'kvmclock_offset' can be negative and its absolute value can be
+	 * slightly greater than 'kernel_ns' because when KVM_SET_CLOCK is
+	 * handled, we use more precise get_kvmclock_ns() there. Make sure
+	 * unsigned 'system_time' doesn't go negative.
+	 */
+	vcpu->hv_clock.system_time = max(kernel_ns + v->kvm->arch.kvmclock_offset,
+					 (s64)0);
 	vcpu->last_guest_tsc = tsc_timestamp;
 
 	/* If the host uses TSC clocksource, then it is stable */
-- 
2.30.2