Re: [PATCH] KVM: x86: Update Xen TSC leaves during CPUID emulation

[Sean Christopherson <seanjc@google.com>]

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@google.com

> 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.