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