+Michael (sashiko was quite stingy with its Cc list)
On Fri, May 15, 2026, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
> - [High] Hyper-V VMs with an invariant TSC but no frequency MSRs lose the
> X86_FEATURE_TSC_RELIABLE capability.
> --
>
> commit 0c0fbc4f0451c30c0e87e0e3591ea4f487eff75c
> Author: Sean Christopherson <[email protected]>
>
> x86/tsc: Pass KNOWN_FREQ and RELIABLE as params to registration
>
> This commit adds a tsc_properties parameter to the paravirtual TSC
> calibration registration routine to consolidate feature flag tracking.
> It updates various hypervisor initialization paths to pass combined flags
> instead of manually setting the CPU capabilities.
>
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -516,8 +516,13 @@ static void __init ms_hyperv_init_platform(void)
> >
> > if (ms_hyperv.features & HV_ACCESS_FREQUENCY_MSRS &&
> > ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) {
> > - tsc_register_calibration_routines(hv_get_tsc_khz,
> > hv_get_tsc_khz);
> > - setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
> > + enum tsc_properties tsc_properties = TSC_FREQUENCY_KNOWN;
> > +
> > + if (ms_hyperv.features & HV_ACCESS_TSC_INVARIANT)
> > + tsc_properties = TSC_FREQ_KNOWN_AND_RELIABLE;
> > +
> > + tsc_register_calibration_routines(hv_get_tsc_khz,
> > hv_get_tsc_khz,
> > + tsc_properties);
> > }
>
> [ ... ]
>
> > @@ -629,7 +634,6 @@ static void __init ms_hyperv_init_platform(void)
> > * is called.
> > */
> > wrmsrq(HV_X64_MSR_TSC_INVARIANT_CONTROL,
> > HV_EXPOSE_INVARIANT_TSC);
> > - setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
> > }
>
> If a Hyper-V VM exposes an invariant TSC but lacks the frequency MSRs,
> does it bypass the tsc_register_calibration_routines() block entirely?
Yes.
> Without the standalone setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE) call
> here, it looks like these VMs will lose the reliable flag.
>
> Will this inadvertently enable the TSC watchdog, potentially causing a
> performance regression if the system falsely marks the TSC as unstable due
> to virtualization scheduling delays?
Hmm, I was going to say that the change was intentional and desriable, but
looking
at this yet again, I don't think that's true. Enabling HV_EXPOSE_INVARIANT_TSC
just means the kernel will (probably) set X86_FEATURE_CONSTANT_TSC and
X86_FEATURE_NONSTOP_TSC during early_init_intel(), AFAICT it doesn't lead to
X86_FEATURE_TSC_RELIABLE being set. And I think in this case, marking the TSC
as reliable makes sense; even if the kernel doesn't user Hyper-V's calibration
info, the host is still clearly telling the guest that the TSC is reliable.
Michael, does keeping the
setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
but also passing TSC_FREQ_KNOWN_AND_RELIABLE to the calibration routine make
sense?
