On Thu, Aug 21, 2025, David Woodhouse wrote: > On Thu, 2025-08-21 at 12:27 -0700, Sean Christopherson wrote: > > > > > The problem with that is that it's been quite unreliable. The kernel > > > doesn't trust it even on chips as recent (hah) as Skylake. I'd be > > > happier to trust what the hypervisor explicitly gives us. But yes, it > > > should be *one* of the sources of information before we reverse- > > > calculate it from the pvclock. > > > > Sorry, by "the VMM use" I mean have the host, e.g. QEMU, explicitly define TSC > > frequency in CPUID.0x15 and CPU frequency in CPUID.0x16. And then on the > > KVM-as-a-guest side of things, trust those leaves when they're available. > > Those leaves are untrustworthy on hardware. Are you suggesting that the > kernel should trust them when it detects that it's running under KVM, > on the assumption that KVM will have corrected them? And that KVM will > be fabricating them even on CPU models which didn't naturally have > those leaves? And that in the presence of TSC scaling, those leaves > will show the right values for the guest even on hypervisors running > today? > > I'll be surprised if that works out well. > > I think I'm a lot happier with the explicit CPUID leaf exposed by the > hypervisor. Why? If the hypervisor is ultimately the one defining the state, why does it matter which CPUID leaf its in?
