On Fri, May 29, 2026, [email protected] wrote:
> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > index 909d3e5e5bcd5..4fe9c69bf40b3 100644
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> [ ... ]
> > @@ -1040,7 +1041,20 @@ static void __init kvm_init_platform(void)
> [ ... ]
> > - kvmclock_init();
> > + /*
> > + * If the TSC counts at a constant frequency across P/T states,
> > counts
> > + * in deep C-states, and the TSC hasn't been marked unstable,
> > treat the
> > + * TSC reliable, as guaranteed by KVM. Note, the TSC unstable
> > check
> > + * exists purely to honor the TSC being marked unstable via command
> > + * line, any runtime detection of an unstable will happen after
> > this.
> > + */
> > + tsc_is_reliable = boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
> > + boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
> > + !check_tsc_unstable();
>
> [Severity: High]
> Does this evaluate check_tsc_unstable() too early to catch the command line
> parameter?
Huh, it does indeed.
> It looks like kvm_init_platform() is called from setup_arch(), but the
> tsc=unstable kernel parameter is parsed via __setup() later during
> parse_args() in start_kernel().
>
> If check_tsc_unstable() evaluates to 0 here because the parameter hasn't
> been parsed yet, wouldn't it incorrectly force X86_FEATURE_TSC_RELIABLE
> and set prefer_tsc to true?
Yep, but this is a pre-existing problem that goes all the way back to the
original
commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if invariant TSC is
exposed").
We could try to fix that, but I'm _very_ strongly inclined to add (yet another)
patch to simply drop the check_tsc_unstable() since it has always been dead
code.
