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@xxxxxxxxxx> --- 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
