Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest and host

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]

On Thu, 2025-09-04 at 06:25 -0700, Sean Christopherson wrote:
> On Thu, Sep 04, 2025, David Woodhouse wrote:
> > On Thu, 2025-09-04 at 04:59 -0700, Sean Christopherson wrote:
> > > 
> > > I thought the original problem being solved was that the _guest_ doesn't know the
> > > effective TSC frequency?  Userspace can already get the effectively TSC frequency
> > > via KVM_GET_TSC_KHZ, why do we need another uAPI to provide that?  (Honest question,
> > > I feel like I'm missing something)
> > 
> > I believe that KVM_GET_TSC_KHZ returns what userspace *asked* for the
> > TSC frequency to be (vcpu->arch.virtual_tsc_khz), not what it actually
> > ended up being based on the measured host frequency and the available
> > scaling granularity (vcpu->hw_tsc_khz).
> 
> Ah, I see where you're coming from.  Purely out of curiosity, have you done the
> math to see if slop would be a problem in practice?  No worries if you haven't,
> just genuinely (and lazily) curious.

It's in the single-digit MHz range generally. Probably not a problem in
practice since the TSC varies with environmental conditions *anyway*
and needs to be refined with NTP/etc.

I'm more interested in getting the scaling information exactly right
for the VMClock case, where we expose microsecond-precision time to the
guest in terms of the TSC.

> Anyways, I'm a-ok reporting that information in KVM_GET_SUPPORTED_CPUID (again,
> only with constant TSC and scaling).  Reporting the effective frequency would be
> useful for the host too, e.g. for sanity checks.  What I specifically want to
> avoid is modifying guest CPUID at runtime.

Hm, in some cases I thought KVM had deliberately moved *to* doing CPUID
updates at runtime, so that its doesn't have to exempt the changable
leaves from the sanity checks which prevent userspace from updating
CPUID for a CPU which has already been run.

It's not just the existing Xen TSC leaf which is updated at runtime in
kvm_cpuid().

But I don't mind too much. If we give userspace a way to *know* the
effective frequency, I'm OK with requiring that userspace do so and
populate the corresponding CPUID leaves for itself, for Xen and KVM
alike. We'd need to expose the FSB frequency too, not just TSC.

I was only going with the runtime update because we are literally
already *doing* it this way in KVM.

> Hmm, the only wrinkle is that, if there is slop, KVM could report different
> information when run on different platforms, e.g. after live migration.  But so
> long as that possibility is documented, I don't think it's truly problematic.
> And it's another argument for not modifying guest CPUID directly; I'd rather let
> userspace figure out whether or not they care about the divergence than silently
> change things from the guest's perspective.
> 
> Alternatively (or in addition to), part of me wants to stealtily update
> KVM_GET_TSC_KHZ to report back the effective frequency, but I can see that being
> problematic, e.g. if a naive VMM reads KVM_GET_TSC_KHZ when saving vCPU state for
> live migration and after enough migrations, the slop ends up drastically skewing
> the guest's frequency.

Indeed. And I also want to tell userspace the precise *ratio* being
applied by hardware scaling, for the VMClock case where userspace
definitely knows *better* about what the host TSC frequency is at this
precise moment, and has to tell the guest what *its* TSC frequency is,
with the same precision.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]