On Fri, Jan 24, 2025, Paul Durrant wrote: > This LGTM. My only concern is whether vcpu->arch.hv_clock will be updated by > anything other than a KVM_REQ_CLOCK_UPDATE? Once the "full" vcpu->arch.hv_clock is gone and only the multiplier+shift are left behind, the probability of rogue changes to those fields should go down. I'll also add a comment explaining the relationship between hw_tsc_khz, pvclock_tsc_shift, and pvclock_tsc_mul, which I should have done it for v1. https://lore.kernel.org/all/20250118005552.2626804-9-seanjc@xxxxxxxxxx > I don't think so but the crucial thing is that the values match what is in > the vcpu_info struct... so maybe a safer option is to pull the values > directly from that. But that relies on the XEN PV clock to be active, which I don't think can be guaranteed. And even if that isn't a concern, I think we're doomed either way if any of the relevant fields get clobbered. Hah, actually we're doomed, period. E.g. if KVM emulates CPUID, and then before resuming the guest reacts to a TSC frequency change, the values returned by CPUID will diverge from what gets stored into the PV clock. In general, if the TSC isn't stable, using the info from CPUID instead of the PV clock itself is a guest bug, because only the PV clock provides a sequence counter to ensure reading time is consistent.
