Re: [PATCH] KVM: x86/xen: improve accuracy of Xen timers
From: Paul Durrant
Date: Tue Oct 31 2023 - 08:22:21 EST
On 31/10/2023 12:11, David Woodhouse wrote:
On 31 October 2023 12:06:17 GMT, Paul Durrant <xadimgnik@xxxxxxxxx> wrote:
On 31/10/2023 11:42, David Woodhouse wrote:
Secondly, it's also wrong thing to do in the general case. Let's say KVM does its thing and snaps the kvmclock backwards in time on a KVM_REQ_CLOCK_UPDATE... do we really want to reinterpret existing timers against the new kvmclock? They were best left alone, I think.
Do we not want to do exactly that? If the master clock is changed, why would we not want to re-interpret the guest's idea of time? That update will be visible to the guest when it re-reads the PV clock source.
Well no, because the guest set that timer *before* we yanked the clock from under it, and probably wants it interpreted in the time scale which was in force at the time it was set.
But more to the point, KVM shouldn't be doing that! We need to *fix* the kvmclock brokenness, not design further band-aids around it.
Ok, fair enough.
As I said, this patch stands even *after* we fix kvmclock, because it handles the timer delta calculation from an single TSC read.
But overengineering a timer reset on KVM_REQ_CLOCK_UPDATE would not.
I'm not sure what you intend to do to kvmlock, so not sure whether we'll
still need the __pvclock_read_cycles(&vcpu->arch.hv_clock, guest_tsc)
but this patch (with the extra check on validity of hv_clock) does fix
the drift so...
Reviewed-by: Paul Durrant <paul@xxxxxxx>