On 22/05/2024 01:17, David Woodhouse wrote:
From: David Woodhouse <dwmw@xxxxxxxxxxxx> There is no reason why the KVM clock cannot be in masterclock mode when the TSCs are not in sync, as long as they are at the same *frequency*. Running at a different frequency would lead to a systemic skew between the clock(s) as observed by different vCPUs due to arithmetic precision in the scaling. So that should indeed force the clock to be based on the host's CLOCK_MONOTONIC_RAW instead of being in masterclock mode where it is defined by the (or 'a') guest TSC. But when the vCPUs merely have a different TSC *offset*, that's not a problem. The offset is applied to that vCPU's kvmclock->tsc_timestamp field, and it all comes out in the wash. So, remove ka->nr_vcpus_matched_tsc and replace it with a new field ka->all_vcpus_matched_tsc which is not only changed to a boolean, but also now tracks that the *frequency* matches, not the precise offset. Using a *count* was always racy because a new vCPU could be being created *while* kvm_track_tsc_matching() was running and comparing with kvm->online_vcpus. That variable is only atomic with respect to itself. In particular, kvm_arch_vcpu_create() runs before kvm->online_vcpus is incremented for the new vCPU, and kvm_arch_vcpu_postcreate() runs later. Repurpose kvm_track_tsc_matching() to be called from kvm_set_tsc_khz(), and kill the cur_tsc_generation/last_tsc_generation fields which tracked the precise TSC matching. Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx> --- arch/x86/include/asm/kvm_host.h | 6 +- arch/x86/kvm/x86.c | 130 +++++++++++++++++--------------- 2 files changed, 71 insertions(+), 65 deletions(-)
Reviewed-by: Paul Durrant <paul@xxxxxxx>
