Re: [PATCH v7 15/36] KVM: x86: Kill last_tsc_{nsec,write,offset} fields

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The S4 backward-TSC adjustment corrupts KVM's master TSC synchronization variables by applying mathematically flawed adjustments, breaking TSC synchronization for vCPUs created after an S4 resume.
--

--- Patch [15]: [PATCH v7 15/36] KVM: x86: Kill last_tsc_{nsec,write,offset} fields ---
commit fe7a0a3f31b36e1ed842426f2ccc55e88a7c3fe0
Author: David Woodhouse <dwmw@amazon.co.uk>

KVM: x86: Kill last_tsc_{nsec,write,offset} fields

This commit removes the redundant last_tsc_* fields in favor of using the
cur_tsc_* fields as the single source of truth for TSC generation state. It
also updates the S4 backwards-TSC adjustment to apply the TSC delta to the
cur_tsc_* tracking variables so future vCPUs synchronize correctly.

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c

[ ... ]

> @@ -9778,13 +9774,18 @@ int kvm_arch_enable_virtualization_cpu(void)
>  			}
>  
>  			/*
> -			 * We have to disable TSC offset matching.. if you were
> -			 * booting a VM while issuing an S4 host suspend....
> -			 * you may have some problem.  Solving this issue is
> -			 * left as an exercise to the reader.
> +			 * Adjust the TSC matching reference by the same
> +			 * delta applied to each vCPU's offset, so that
> +			 * future KVM_SET_TSC / vCPU creation still matches
> +			 * correctly against the adjusted TSC timeline.
> +			 * Scale from host to guest TSC rate.
>  			 */
> -			kvm->arch.last_tsc_nsec = 0;
> -			kvm->arch.last_tsc_write = 0;
> +			raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
> +			kvm->arch.cur_tsc_write -=
> +				kvm_scale_tsc(delta_cyc,
> +					      kvm->arch.cur_tsc_scaling_ratio);
> +			kvm->arch.cur_tsc_offset += delta_cyc;

[Severity: High]
Is delta_cyc correctly scaled here before being added to cur_tsc_offset? 

delta_cyc represents host cycles, but it is being added directly to 
cur_tsc_offset. If the guest has a different TSC scaling ratio, could adding 
unscaled host cycles to the offset cause desynchronization for newly 
hotplugged vCPUs?

Additionally, does subtracting the scaled delta_cyc from cur_tsc_write shift 
the guest TSC reference too far backwards? delta_cyc in this context 
represents the host's entire pre-suspend uptime. Because elapsed time relies 
on CLOCK_MONOTONIC_RAW (which pauses during suspend, preserving time 
continuity), subtracting the entire pre-suspend uptime might artificially 
shift the reference and break the 1-second synchronization window for vCPUs 
created after the S4 resume.

> +			raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags);
>  		}
>  
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728144954.355376-1-dwmw2@infradead.org?part=15