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

[Sean Christopherson <seanjc@google.com>]

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?