Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The patch attempts to decouple CPU frequency from Secure TSC frequency for SNP guests, but a downstream core x86 check defeats this logic if the frequencies differ by more than 10%. --
--- Patch [6]: [PATCH v6 06/51] x86/sev: Don't override CPU frequency calibration for SNP's Secure TSC --- commit fde9a60ee57bc9ae26f0e19e9b9a2405fdf1fe11 Author: Sean Christopherson <[email protected]> x86/sev: Don't override CPU frequency calibration for SNP's Secure TSC This commit removes the override of the kernel's CPU frequency calibration routine for SNP guests with Secure TSC. It aims to allow the CPU frequency to be calibrated independently of the TSC frequency. > diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c > index ed0ac52a765e0..665de1aea0ee9 100644 > --- a/arch/x86/coco/sev/core.c > +++ b/arch/x86/coco/sev/core.c > @@ -2046,7 +2046,6 @@ void __init snp_secure_tsc_init(void) > > snp_tsc_freq_khz = SNP_SCALE_TSC_FREQ(tsc_freq_mhz * 1000, > secrets->tsc_factor); > > - x86_platform.calibrate_cpu = securetsc_get_tsc_khz; [Severity: Medium] Does this actually decouple the frequencies if they differ significantly? If the independent CPU calibration determines a frequency that differs from the Secure TSC frequency by more than 10%, the core x86 code will still overwrite it. Looking at determine_cpu_tsc_frequencies() in arch/x86/kernel/tsc.c: if (cpu_khz == 0) cpu_khz = tsc_khz; else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz) cpu_khz = tsc_khz; Will this downstream sanity check silently clamp cpu_khz back to tsc_khz anyway, defeating the patch's attempt to keep them separate when APERF/MPERF values diverge? > x86_platform.calibrate_tsc = securetsc_get_tsc_khz; > > early_memunmap(mem, PAGE_SIZE); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
