Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Unconditionally setting X86_FEATURE_TSC_KNOWN_FREQ skips TSC refinement even if the hypervisor fails to provide a valid TSC frequency. --
commit 44594dfd95dd7a3adcfc1b7f3c8d37e15ed4e143 Author: Sean Christopherson <[email protected]> x86/acrn: Mark TSC frequency as known when using ACRN for calibration This commit marks the TSC frequency as known when using ACRN's PV CPUID information, assuming the hypervisor explicitly provides it. > diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c > index ad8f2da8003b3..0303fe6a2efa7 100644 > --- a/arch/x86/kernel/cpu/acrn.c > +++ b/arch/x86/kernel/cpu/acrn.c > @@ -33,6 +33,8 @@ static void __init acrn_init_platform(void) > { > /* Install system interrupt handler for ACRN hypervisor callback */ > sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_acrn_hv_callback); > + > + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); [Severity: Medium] Does this unconditionally skip TSC refinement even if the hypervisor fails to provide a valid TSC frequency? ACRN TSC frequency is obtained via acrn_get_tsc_khz(), which queries cpuid_eax(ACRN_CPUID_TIMING_INFO). If the hypervisor does not support this leaf or returns 0, the kernel falls back to early hardware calibration (e.g., PIT/HPET via x86_platform.calibrate_tsc()). Because X86_FEATURE_TSC_KNOWN_FREQ is unconditionally forced here, init_tsc_clocksource() will assume the frequency is known and skip the refined calibration phase. This regression locks in the imprecise early calibration and could cause time drift. I see this regression was addressed in a later commit b0e7d8e1edd52 ("x86/tsc: Consolidate forcing of X86_FEATURE_TSC_KNOWN_FREQ for PV code") which correctly gates the capability setting on known_tsc_khz != 0. > } > > static bool acrn_x2apic_available(void) -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=9
