Message ID | 20231018195638.1898375-1-seanjc@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp5033069vqb; Wed, 18 Oct 2023 12:57:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFKU779yzO6fdnFnI8AIKPWmSaN/K8ui7XCtxRsIxrnlrDzZNqdUyQYLjTkJ/9sl4AvmOTV X-Received: by 2002:a05:6358:ca6:b0:143:8084:e625 with SMTP id o38-20020a0563580ca600b001438084e625mr12914rwj.11.1697659033185; Wed, 18 Oct 2023 12:57:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697659033; cv=none; d=google.com; s=arc-20160816; b=nKZM5k2xljReIXHAFjB6ArlDodz+TuEEQ+iDHsdj1+5I4Ngdl5xAcEDYVD+vV6QGsC DoLOc9p725XdnoLqom+inApqvF9zUzunGrK8HDPJHDoNq/yq9M7h5F9sAbxpqYHd1bht GfSGhsaiaUuMbQb/BfjDswmrSbOuOpUKNUUDjI89aUJbFisiOJrXNT+sbU+fEMcPPWz1 MOH9/+UDDv0sr6eHii9s3mcgQVOpYF4tCL4804tlFmfpyapnmkQrrq00otpLU4YFqIF1 ZolrryqQn2MQvn8b7ysW3eY13wHqWKyxht+mRaIA6YN4mtNMtBdwAdayMt6tXXJL59Fk PhiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :reply-to:dkim-signature; bh=7Px1WBvBiMUlKzpscWsJjyfSW5bylu5iQGwjDIacRRw=; fh=XxM2S7/AdVCNHdOlocZ3Ruonn9HKgC+VyRyuqBqhweo=; b=py0F69FvC36kaexDTcKXiVBVZfhLPrmn6kHZrhN2jujGmeZYpI3JrEkTIGrA4BS3Dm cwx/d6ZylSWzJRPaW0nsj1qBH+zKiFUmPyGPAOgXyfCfEhh6Jn0OGUX0LFge7spxiPQS HMZF8cLciqc/WiUjABJaaqSDN+aYr3nqu01VOAhJkaelQXNpeFXOqAOT+H8Vyt6OIgkM 2me42uNOaTNhg8uQm06mtM1U4Ib2cQJUP30Lc6X6hl28P0/vHtVRfMiQMfd3u/HwR4zF /lRGm8s4xjW9hAPQIQD6uPSdjJtCCOmMD72vW9z8MgEhD9LNjC16gqIbPmTGnzymdHsO gsyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=WSCUtZHs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id s62-20020a632c41000000b00584b9d0ff80si2746289pgs.127.2023.10.18.12.57.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 12:57:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=WSCUtZHs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id D6B5D80DB701; Wed, 18 Oct 2023 12:57:08 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231486AbjJRT4q (ORCPT <rfc822;zwp10758@gmail.com> + 24 others); Wed, 18 Oct 2023 15:56:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229702AbjJRT4o (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 18 Oct 2023 15:56:44 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89CE8B8 for <linux-kernel@vger.kernel.org>; Wed, 18 Oct 2023 12:56:42 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d9a3e5f1742so10579567276.0 for <linux-kernel@vger.kernel.org>; Wed, 18 Oct 2023 12:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697659001; x=1698263801; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=7Px1WBvBiMUlKzpscWsJjyfSW5bylu5iQGwjDIacRRw=; b=WSCUtZHs1URuDak4Mfsny32PPZfosW01uye3kaefIhQUbTd+VrHG2NkUX5UIAKTF3t 55NEmv2MlS2G81Sg4fD0qLUd+X6N6P5ff9USxREQ2SttNvyerIOrz30VOCGl9zseakdm ZmLb38a4ZCWH13hbgYTugnL3kIVehlT0Dow1qeeYhnBC5splTgC8FJ6mfldK7ba7D8Bt UJ/q+jqWlJgDF4so5Zy4O355nUJAjqOqNvcbrbi5El+Akx5C2IoHBB6+VY99TBlIvl4U N9ufIZt5d3ncVzZSdx2SS5dwAXqH7aLbrEFhiuECNLc5arCSSivCGu3/iHN5V0QRce0C yjNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697659001; x=1698263801; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7Px1WBvBiMUlKzpscWsJjyfSW5bylu5iQGwjDIacRRw=; b=j4ALDGb8eXeiBqUfcp9LZbqKuMfrE8q3iD3CDy13w6qDt/PS8fznL7+jnXgrMHCOPp Iu5cN3Oe/lUi+hADOLzOhpRJZ+usc7YZ2ft8PCC67xRxSRRy88EwY+Pf3V57/po3iygQ nvkPEaHfis2RXK3i7NWfEuRgmdYYS1srnTKbuhPb3pi9otiji92GBdYyyWkF/yxYTw4Q gGelUSUjvoF5E9I9i8rNCvQKAtPP7o3nulebd+YDrq/bBtwTJWS0v/vaGaRWqzyebSTB A1bzQ5N6CBK4ewLlFPbd8tWrKo7yCkhPtpXsTqvfK22sQlvCjbLMCmGpB/TZNv40OLHG oFng== X-Gm-Message-State: AOJu0YyphFjk79oXPmbeN8urVuVFLzoOWyTYQMVLfhF83wkflaGKqIiM oDhnc4JCwOYAOpVrZsyA9zunAyGpqSE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:fd6:0:b0:d9a:3d02:b55 with SMTP id 205-20020a250fd6000000b00d9a3d020b55mr10226ybp.0.1697659001238; Wed, 18 Oct 2023 12:56:41 -0700 (PDT) Reply-To: Sean Christopherson <seanjc@google.com> Date: Wed, 18 Oct 2023 12:56:38 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.42.0.655.g421f12c284-goog Message-ID: <20231018195638.1898375-1-seanjc@google.com> Subject: [PATCH] KVM: x86: Don't unnecessarily force masterclock update on vCPU hotplug From: Sean Christopherson <seanjc@google.com> To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Dongli Zhang <dongli.zhang@oracle.com>, David Woodhouse <dwmw2@infradead.org> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 18 Oct 2023 12:57:08 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780124518251528552 X-GMAIL-MSGID: 1780124518251528552 |
Series |
KVM: x86: Don't unnecessarily force masterclock update on vCPU hotplug
|
|
Commit Message
Sean Christopherson
Oct. 18, 2023, 7:56 p.m. UTC
Don't force a masterclock update when a vCPU synchronizes to the current
TSC generation, e.g. when userspace hotplugs a pre-created vCPU into the
VM. Unnecessarily updating the masterclock is undesirable as it can cause
kvmclock's time to jump, which is particularly painful on systems with a
stable TSC as kvmclock _should_ be fully reliable on such systems.
The unexpected time jumps are due to differences in the TSC=>nanoseconds
conversion algorithms between kvmclock and the host's CLOCK_MONOTONIC_RAW
(the pvclock algorithm is inherently lossy). When updating the
masterclock, KVM refreshes the "base", i.e. moves the elapsed time since
the last update from the kvmclock/pvclock algorithm to the
CLOCK_MONOTONIC_RAW algorithm. Synchronizing kvmclock with
CLOCK_MONOTONIC_RAW is the lesser of evils when the TSC is unstable, but
adds no real value when the TSC is stable.
Prior to commit 7f187922ddf6 ("KVM: x86: update masterclock values on TSC
writes"), KVM did NOT force an update when synchronizing a vCPU to the
current generation.
commit 7f187922ddf6b67f2999a76dcb71663097b75497
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Tue Nov 4 21:30:44 2014 -0200
KVM: x86: update masterclock values on TSC writes
When the guest writes to the TSC, the masterclock TSC copy must be
updated as well along with the TSC_OFFSET update, otherwise a negative
tsc_timestamp is calculated at kvm_guest_time_update.
Once "if (!vcpus_matched && ka->use_master_clock)" is simplified to
"if (ka->use_master_clock)", the corresponding "if (!ka->use_master_clock)"
becomes redundant, so remove the do_request boolean and collapse
everything into a single condition.
Before that, KVM only re-synced the masterclock if the masterclock was
enabled or disabled Note, at the time of the above commit, VMX
synchronized TSC on *guest* writes to MSR_IA32_TSC:
case MSR_IA32_TSC:
kvm_write_tsc(vcpu, msr_info);
break;
which is why the changelog specifically says "guest writes", but the bug
that was being fixed wasn't unique to guest write, i.e. a TSC write from
the host would suffer the same problem.
So even though KVM stopped synchronizing on guest writes as of commit
0c899c25d754 ("KVM: x86: do not attempt TSC synchronization on guest
writes"), simply reverting commit 7f187922ddf6 is not an option. Figuring
out how a negative tsc_timestamp could be computed requires a bit more
sleuthing.
In kvm_write_tsc() (at the time), except for KVM's "less than 1 second"
hack, KVM snapshotted the vCPU's current TSC *and* the current time in
nanoseconds, where kvm->arch.cur_tsc_nsec is the current host kernel time
in nanoseconds:
ns = get_kernel_ns();
...
if (usdiff < USEC_PER_SEC &&
vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) {
...
} else {
/*
* We split periods of matched TSC writes into generations.
* For each generation, we track the original measured
* nanosecond time, offset, and write, so if TSCs are in
* sync, we can match exact offset, and if not, we can match
* exact software computation in compute_guest_tsc()
*
* These values are tracked in kvm->arch.cur_xxx variables.
*/
kvm->arch.cur_tsc_generation++;
kvm->arch.cur_tsc_nsec = ns;
kvm->arch.cur_tsc_write = data;
kvm->arch.cur_tsc_offset = offset;
matched = false;
pr_debug("kvm: new tsc generation %llu, clock %llu\n",
kvm->arch.cur_tsc_generation, data);
}
...
/* Keep track of which generation this VCPU has synchronized to */
vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation;
vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec;
vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write;
Note that the above creates a new generation and sets "matched" to false!
But because kvm_track_tsc_matching() looks for matched+1, i.e. doesn't
require the vCPU that creates the new generation to match itself, KVM
would immediately compute vcpus_matched as true for VMs with a single vCPU.
As a result, KVM would skip the masterlock update, even though a new TSC
generation was created:
vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 ==
atomic_read(&vcpu->kvm->online_vcpus));
if (vcpus_matched && gtod->clock.vclock_mode == VCLOCK_TSC)
if (!ka->use_master_clock)
do_request = 1;
if (!vcpus_matched && ka->use_master_clock)
do_request = 1;
if (do_request)
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
On hardware without TSC scaling support, vcpu->tsc_catchup is set to true
if the guest TSC frequency is faster than the host TSC frequency, even if
the TSC is otherwise stable. And for that mode, kvm_guest_time_update(),
by way of compute_guest_tsc(), uses vcpu->arch.this_tsc_nsec, a.k.a. the
kernel time at the last TSC write, to compute the guest TSC relative to
kernel time:
static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns)
{
u64 tsc = pvclock_scale_delta(kernel_ns-vcpu->arch.this_tsc_nsec,
vcpu->arch.virtual_tsc_mult,
vcpu->arch.virtual_tsc_shift);
tsc += vcpu->arch.this_tsc_write;
return tsc;
}
Except the "kernel_ns" passed to compute_guest_tsc() isn't the current
kernel time, it's the masterclock snapshot!
spin_lock(&ka->pvclock_gtod_sync_lock);
use_master_clock = ka->use_master_clock;
if (use_master_clock) {
host_tsc = ka->master_cycle_now;
kernel_ns = ka->master_kernel_ns;
}
spin_unlock(&ka->pvclock_gtod_sync_lock);
if (vcpu->tsc_catchup) {
u64 tsc = compute_guest_tsc(v, kernel_ns);
if (tsc > tsc_timestamp) {
adjust_tsc_offset_guest(v, tsc - tsc_timestamp);
tsc_timestamp = tsc;
}
}
And so when KVM skips the masterclock update after a TSC write, i.e. after
a new TSC generation is started, the "kernel_ns-vcpu->arch.this_tsc_nsec"
is *guaranteed* to generate a negative value, because this_tsc_nsec was
captured after ka->master_kernel_ns.
Forcing a masterclock update essentially fudged around that problem, but
in a heavy handed way that introduced undesirable side effects, i.e.
unnecessarily forces a masterclock update when a new vCPU joins the party
via hotplug.
Note, KVM forces masterclock updates in other weird ways that are also
likely unnecessary, e.g. when establishing a new Xen shared info page and
when userspace creates a brand new vCPU. But the Xen thing is firmly a
separate mess, and there are no known userspace VMMs that utilize kvmclock
*and* create new vCPUs after the VM is up and running. I.e. the other
issues are future problems.
Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
Closes: https://lore.kernel.org/all/20230926230649.67852-1-dongli.zhang@oracle.com
Fixes: 7f187922ddf6 ("KVM: x86: update masterclock values on TSC writes")
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/x86.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
base-commit: 437bba5ad2bba00c2056c896753a32edf80860cc
Comments
Tested-by: Dongli Zhang <dongli.zhang@oracle.com> I did the test with below KVM patch, to calculate the kvmclock at the hypervisor side. --- arch/x86/kvm/x86.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b0c47b4..9ddc437 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3068,6 +3068,11 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) u64 tsc_timestamp, host_tsc; u8 pvclock_flags; bool use_master_clock; + struct pvclock_vcpu_time_info old_hv_clock; + u64 tsc, old_ns, new_ns, diff; + bool backward; + + memcpy(&old_hv_clock, &vcpu->hv_clock, sizeof(old_hv_clock)); kernel_ns = 0; host_tsc = 0; @@ -3144,6 +3149,25 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) vcpu->hv_clock.flags = pvclock_flags; + tsc = rdtsc(); + tsc = kvm_read_l1_tsc(v, tsc); + old_ns = __pvclock_read_cycles(&old_hv_clock, tsc); + new_ns = __pvclock_read_cycles(&vcpu->hv_clock, tsc); + if (old_ns > new_ns) { + backward = true; + diff = old_ns - new_ns; + } else { + backward = false; + diff = new_ns - old_ns; + } + pr_alert("orabug: kvm_guest_time_update() vcpu=%d, tsc=%llu, backward=%d, diff=%llu, old_ns=%llu, new_ns=%llu\n" + "old (%u, %llu, %llu, %u, %d, %u), new (%u, %llu, %llu, %u, %d, %u)", + v->vcpu_id, tsc, backward, diff, old_ns, new_ns, + old_hv_clock.version, old_hv_clock.tsc_timestamp, old_hv_clock.system_time, + old_hv_clock.tsc_to_system_mul, old_hv_clock.tsc_shift, old_hv_clock.flags, + vcpu->hv_clock.version, vcpu->hv_clock.tsc_timestamp, vcpu->hv_clock.system_time, + vcpu->hv_clock.tsc_to_system_mul, vcpu->hv_clock.tsc_shift, vcpu->hv_clock.flags); + if (vcpu->pv_time.active) kvm_setup_guest_pvclock(v, &vcpu->pv_time, 0); if (vcpu->xen.vcpu_info_cache.active) -- Dongli Zhang On 10/18/23 12:56, Sean Christopherson wrote: > Don't force a masterclock update when a vCPU synchronizes to the current > TSC generation, e.g. when userspace hotplugs a pre-created vCPU into the > VM. Unnecessarily updating the masterclock is undesirable as it can cause > kvmclock's time to jump, which is particularly painful on systems with a > stable TSC as kvmclock _should_ be fully reliable on such systems. > > The unexpected time jumps are due to differences in the TSC=>nanoseconds > conversion algorithms between kvmclock and the host's CLOCK_MONOTONIC_RAW > (the pvclock algorithm is inherently lossy). When updating the > masterclock, KVM refreshes the "base", i.e. moves the elapsed time since > the last update from the kvmclock/pvclock algorithm to the > CLOCK_MONOTONIC_RAW algorithm. Synchronizing kvmclock with > CLOCK_MONOTONIC_RAW is the lesser of evils when the TSC is unstable, but > adds no real value when the TSC is stable. > > Prior to commit 7f187922ddf6 ("KVM: x86: update masterclock values on TSC > writes"), KVM did NOT force an update when synchronizing a vCPU to the > current generation. > > commit 7f187922ddf6b67f2999a76dcb71663097b75497 > Author: Marcelo Tosatti <mtosatti@redhat.com> > Date: Tue Nov 4 21:30:44 2014 -0200 > > KVM: x86: update masterclock values on TSC writes > > When the guest writes to the TSC, the masterclock TSC copy must be > updated as well along with the TSC_OFFSET update, otherwise a negative > tsc_timestamp is calculated at kvm_guest_time_update. > > Once "if (!vcpus_matched && ka->use_master_clock)" is simplified to > "if (ka->use_master_clock)", the corresponding "if (!ka->use_master_clock)" > becomes redundant, so remove the do_request boolean and collapse > everything into a single condition. > > Before that, KVM only re-synced the masterclock if the masterclock was > enabled or disabled Note, at the time of the above commit, VMX > synchronized TSC on *guest* writes to MSR_IA32_TSC: > > case MSR_IA32_TSC: > kvm_write_tsc(vcpu, msr_info); > break; > > which is why the changelog specifically says "guest writes", but the bug > that was being fixed wasn't unique to guest write, i.e. a TSC write from > the host would suffer the same problem. > > So even though KVM stopped synchronizing on guest writes as of commit > 0c899c25d754 ("KVM: x86: do not attempt TSC synchronization on guest > writes"), simply reverting commit 7f187922ddf6 is not an option. Figuring > out how a negative tsc_timestamp could be computed requires a bit more > sleuthing. > > In kvm_write_tsc() (at the time), except for KVM's "less than 1 second" > hack, KVM snapshotted the vCPU's current TSC *and* the current time in > nanoseconds, where kvm->arch.cur_tsc_nsec is the current host kernel time > in nanoseconds: > > ns = get_kernel_ns(); > > ... > > if (usdiff < USEC_PER_SEC && > vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) { > ... > } else { > /* > * We split periods of matched TSC writes into generations. > * For each generation, we track the original measured > * nanosecond time, offset, and write, so if TSCs are in > * sync, we can match exact offset, and if not, we can match > * exact software computation in compute_guest_tsc() > * > * These values are tracked in kvm->arch.cur_xxx variables. > */ > kvm->arch.cur_tsc_generation++; > kvm->arch.cur_tsc_nsec = ns; > kvm->arch.cur_tsc_write = data; > kvm->arch.cur_tsc_offset = offset; > matched = false; > pr_debug("kvm: new tsc generation %llu, clock %llu\n", > kvm->arch.cur_tsc_generation, data); > } > > ... > > /* Keep track of which generation this VCPU has synchronized to */ > vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation; > vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec; > vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write; > > Note that the above creates a new generation and sets "matched" to false! > But because kvm_track_tsc_matching() looks for matched+1, i.e. doesn't > require the vCPU that creates the new generation to match itself, KVM > would immediately compute vcpus_matched as true for VMs with a single vCPU. > As a result, KVM would skip the masterlock update, even though a new TSC > generation was created: > > vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 == > atomic_read(&vcpu->kvm->online_vcpus)); > > if (vcpus_matched && gtod->clock.vclock_mode == VCLOCK_TSC) > if (!ka->use_master_clock) > do_request = 1; > > if (!vcpus_matched && ka->use_master_clock) > do_request = 1; > > if (do_request) > kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu); > > On hardware without TSC scaling support, vcpu->tsc_catchup is set to true > if the guest TSC frequency is faster than the host TSC frequency, even if > the TSC is otherwise stable. And for that mode, kvm_guest_time_update(), > by way of compute_guest_tsc(), uses vcpu->arch.this_tsc_nsec, a.k.a. the > kernel time at the last TSC write, to compute the guest TSC relative to > kernel time: > > static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns) > { > u64 tsc = pvclock_scale_delta(kernel_ns-vcpu->arch.this_tsc_nsec, > vcpu->arch.virtual_tsc_mult, > vcpu->arch.virtual_tsc_shift); > tsc += vcpu->arch.this_tsc_write; > return tsc; > } > > Except the "kernel_ns" passed to compute_guest_tsc() isn't the current > kernel time, it's the masterclock snapshot! > > spin_lock(&ka->pvclock_gtod_sync_lock); > use_master_clock = ka->use_master_clock; > if (use_master_clock) { > host_tsc = ka->master_cycle_now; > kernel_ns = ka->master_kernel_ns; > } > spin_unlock(&ka->pvclock_gtod_sync_lock); > > if (vcpu->tsc_catchup) { > u64 tsc = compute_guest_tsc(v, kernel_ns); > if (tsc > tsc_timestamp) { > adjust_tsc_offset_guest(v, tsc - tsc_timestamp); > tsc_timestamp = tsc; > } > } > > And so when KVM skips the masterclock update after a TSC write, i.e. after > a new TSC generation is started, the "kernel_ns-vcpu->arch.this_tsc_nsec" > is *guaranteed* to generate a negative value, because this_tsc_nsec was > captured after ka->master_kernel_ns. > > Forcing a masterclock update essentially fudged around that problem, but > in a heavy handed way that introduced undesirable side effects, i.e. > unnecessarily forces a masterclock update when a new vCPU joins the party > via hotplug. > > Note, KVM forces masterclock updates in other weird ways that are also > likely unnecessary, e.g. when establishing a new Xen shared info page and > when userspace creates a brand new vCPU. But the Xen thing is firmly a > separate mess, and there are no known userspace VMMs that utilize kvmclock > *and* create new vCPUs after the VM is up and running. I.e. the other > issues are future problems. > > Reported-by: Dongli Zhang <dongli.zhang@oracle.com> > Closes: https://urldefense.com/v3/__https://lore.kernel.org/all/20230926230649.67852-1-dongli.zhang@oracle.com__;!!ACWV5N9M2RV99hQ!N3CdrL7gBde6tjlPxmd0cuqYCaVI4VGrvIqGX5I5pNx-cL_srMa6VuXUwrFXAA7nMgPXRvzndIOCkz-r1w$ > Fixes: 7f187922ddf6 ("KVM: x86: update masterclock values on TSC writes") > Cc: David Woodhouse <dwmw2@infradead.org> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/x86.c | 29 ++++++++++++++++------------- > 1 file changed, 16 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 530d4bc2259b..61bdb6c1d000 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -2510,26 +2510,29 @@ static inline int gtod_is_based_on_tsc(int mode) > } > #endif > > -static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) > +static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation) > { > #ifdef CONFIG_X86_64 > - bool vcpus_matched; > struct kvm_arch *ka = &vcpu->kvm->arch; > struct pvclock_gtod_data *gtod = &pvclock_gtod_data; > > - vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 == > - atomic_read(&vcpu->kvm->online_vcpus)); > + /* > + * To use the masterclock, the host clocksource must be based on TSC > + * and all vCPUs must have matching TSCs. Note, the count for matching > + * vCPUs doesn't include the reference vCPU, hence "+1". > + */ > + bool use_master_clock = (ka->nr_vcpus_matched_tsc + 1 == > + atomic_read(&vcpu->kvm->online_vcpus)) && > + gtod_is_based_on_tsc(gtod->clock.vclock_mode); > > /* > - * Once the masterclock is enabled, always perform request in > - * order to update it. > - * > - * In order to enable masterclock, the host clocksource must be TSC > - * and the vcpus need to have matched TSCs. When that happens, > - * perform request to enable masterclock. > + * Request a masterclock update if the masterclock needs to be toggled > + * on/off, or when starting a new generation and the masterclock is > + * enabled (compute_guest_tsc() requires the masterclock snapshot to be > + * taken _after_ the new generation is created). > */ > - if (ka->use_master_clock || > - (gtod_is_based_on_tsc(gtod->clock.vclock_mode) && vcpus_matched)) > + if ((ka->use_master_clock && new_generation) || > + (ka->use_master_clock != use_master_clock)) > kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu); > > trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc, > @@ -2706,7 +2709,7 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc, > vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec; > vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write; > > - kvm_track_tsc_matching(vcpu); > + kvm_track_tsc_matching(vcpu, !matched); > } > > static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value) > > base-commit: 437bba5ad2bba00c2056c896753a32edf80860cc
Hi Sean, Would mind sharing if the patch is waiting for Reviewed-by, and when it will be merged into kvm-x86 tree? While I not sure if the same developer can give both Tested-by and Reviewed-by ... Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com> Thank you very much! Dongli Zhang On 10/20/23 00:45, Dongli Zhang wrote: > Tested-by: Dongli Zhang <dongli.zhang@oracle.com> > > > I did the test with below KVM patch, to calculate the kvmclock at the hypervisor > side. > > --- > arch/x86/kvm/x86.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index b0c47b4..9ddc437 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3068,6 +3068,11 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) > u64 tsc_timestamp, host_tsc; > u8 pvclock_flags; > bool use_master_clock; > + struct pvclock_vcpu_time_info old_hv_clock; > + u64 tsc, old_ns, new_ns, diff; > + bool backward; > + > + memcpy(&old_hv_clock, &vcpu->hv_clock, sizeof(old_hv_clock)); > > kernel_ns = 0; > host_tsc = 0; > @@ -3144,6 +3149,25 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) > > vcpu->hv_clock.flags = pvclock_flags; > > + tsc = rdtsc(); > + tsc = kvm_read_l1_tsc(v, tsc); > + old_ns = __pvclock_read_cycles(&old_hv_clock, tsc); > + new_ns = __pvclock_read_cycles(&vcpu->hv_clock, tsc); > + if (old_ns > new_ns) { > + backward = true; > + diff = old_ns - new_ns; > + } else { > + backward = false; > + diff = new_ns - old_ns; > + } > + pr_alert("orabug: kvm_guest_time_update() vcpu=%d, tsc=%llu, backward=%d, > diff=%llu, old_ns=%llu, new_ns=%llu\n" > + "old (%u, %llu, %llu, %u, %d, %u), new (%u, %llu, %llu, %u, %d, %u)", > + v->vcpu_id, tsc, backward, diff, old_ns, new_ns, > + old_hv_clock.version, old_hv_clock.tsc_timestamp, old_hv_clock.system_time, > + old_hv_clock.tsc_to_system_mul, old_hv_clock.tsc_shift, old_hv_clock.flags, > + vcpu->hv_clock.version, vcpu->hv_clock.tsc_timestamp, > vcpu->hv_clock.system_time, > + vcpu->hv_clock.tsc_to_system_mul, vcpu->hv_clock.tsc_shift, > vcpu->hv_clock.flags); > + > if (vcpu->pv_time.active) > kvm_setup_guest_pvclock(v, &vcpu->pv_time, 0); > if (vcpu->xen.vcpu_info_cache.active) > -- > > Dongli Zhang > > On 10/18/23 12:56, Sean Christopherson wrote: >> Don't force a masterclock update when a vCPU synchronizes to the current >> TSC generation, e.g. when userspace hotplugs a pre-created vCPU into the >> VM. Unnecessarily updating the masterclock is undesirable as it can cause >> kvmclock's time to jump, which is particularly painful on systems with a >> stable TSC as kvmclock _should_ be fully reliable on such systems. >> >> The unexpected time jumps are due to differences in the TSC=>nanoseconds >> conversion algorithms between kvmclock and the host's CLOCK_MONOTONIC_RAW >> (the pvclock algorithm is inherently lossy). When updating the >> masterclock, KVM refreshes the "base", i.e. moves the elapsed time since >> the last update from the kvmclock/pvclock algorithm to the >> CLOCK_MONOTONIC_RAW algorithm. Synchronizing kvmclock with >> CLOCK_MONOTONIC_RAW is the lesser of evils when the TSC is unstable, but >> adds no real value when the TSC is stable. >> >> Prior to commit 7f187922ddf6 ("KVM: x86: update masterclock values on TSC >> writes"), KVM did NOT force an update when synchronizing a vCPU to the >> current generation. >> >> commit 7f187922ddf6b67f2999a76dcb71663097b75497 >> Author: Marcelo Tosatti <mtosatti@redhat.com> >> Date: Tue Nov 4 21:30:44 2014 -0200 >> >> KVM: x86: update masterclock values on TSC writes >> >> When the guest writes to the TSC, the masterclock TSC copy must be >> updated as well along with the TSC_OFFSET update, otherwise a negative >> tsc_timestamp is calculated at kvm_guest_time_update. >> >> Once "if (!vcpus_matched && ka->use_master_clock)" is simplified to >> "if (ka->use_master_clock)", the corresponding "if (!ka->use_master_clock)" >> becomes redundant, so remove the do_request boolean and collapse >> everything into a single condition. >> >> Before that, KVM only re-synced the masterclock if the masterclock was >> enabled or disabled Note, at the time of the above commit, VMX >> synchronized TSC on *guest* writes to MSR_IA32_TSC: >> >> case MSR_IA32_TSC: >> kvm_write_tsc(vcpu, msr_info); >> break; >> >> which is why the changelog specifically says "guest writes", but the bug >> that was being fixed wasn't unique to guest write, i.e. a TSC write from >> the host would suffer the same problem. >> >> So even though KVM stopped synchronizing on guest writes as of commit >> 0c899c25d754 ("KVM: x86: do not attempt TSC synchronization on guest >> writes"), simply reverting commit 7f187922ddf6 is not an option. Figuring >> out how a negative tsc_timestamp could be computed requires a bit more >> sleuthing. >> >> In kvm_write_tsc() (at the time), except for KVM's "less than 1 second" >> hack, KVM snapshotted the vCPU's current TSC *and* the current time in >> nanoseconds, where kvm->arch.cur_tsc_nsec is the current host kernel time >> in nanoseconds: >> >> ns = get_kernel_ns(); >> >> ... >> >> if (usdiff < USEC_PER_SEC && >> vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) { >> ... >> } else { >> /* >> * We split periods of matched TSC writes into generations. >> * For each generation, we track the original measured >> * nanosecond time, offset, and write, so if TSCs are in >> * sync, we can match exact offset, and if not, we can match >> * exact software computation in compute_guest_tsc() >> * >> * These values are tracked in kvm->arch.cur_xxx variables. >> */ >> kvm->arch.cur_tsc_generation++; >> kvm->arch.cur_tsc_nsec = ns; >> kvm->arch.cur_tsc_write = data; >> kvm->arch.cur_tsc_offset = offset; >> matched = false; >> pr_debug("kvm: new tsc generation %llu, clock %llu\n", >> kvm->arch.cur_tsc_generation, data); >> } >> >> ... >> >> /* Keep track of which generation this VCPU has synchronized to */ >> vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation; >> vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec; >> vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write; >> >> Note that the above creates a new generation and sets "matched" to false! >> But because kvm_track_tsc_matching() looks for matched+1, i.e. doesn't >> require the vCPU that creates the new generation to match itself, KVM >> would immediately compute vcpus_matched as true for VMs with a single vCPU. >> As a result, KVM would skip the masterlock update, even though a new TSC >> generation was created: >> >> vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 == >> atomic_read(&vcpu->kvm->online_vcpus)); >> >> if (vcpus_matched && gtod->clock.vclock_mode == VCLOCK_TSC) >> if (!ka->use_master_clock) >> do_request = 1; >> >> if (!vcpus_matched && ka->use_master_clock) >> do_request = 1; >> >> if (do_request) >> kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu); >> >> On hardware without TSC scaling support, vcpu->tsc_catchup is set to true >> if the guest TSC frequency is faster than the host TSC frequency, even if >> the TSC is otherwise stable. And for that mode, kvm_guest_time_update(), >> by way of compute_guest_tsc(), uses vcpu->arch.this_tsc_nsec, a.k.a. the >> kernel time at the last TSC write, to compute the guest TSC relative to >> kernel time: >> >> static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns) >> { >> u64 tsc = pvclock_scale_delta(kernel_ns-vcpu->arch.this_tsc_nsec, >> vcpu->arch.virtual_tsc_mult, >> vcpu->arch.virtual_tsc_shift); >> tsc += vcpu->arch.this_tsc_write; >> return tsc; >> } >> >> Except the "kernel_ns" passed to compute_guest_tsc() isn't the current >> kernel time, it's the masterclock snapshot! >> >> spin_lock(&ka->pvclock_gtod_sync_lock); >> use_master_clock = ka->use_master_clock; >> if (use_master_clock) { >> host_tsc = ka->master_cycle_now; >> kernel_ns = ka->master_kernel_ns; >> } >> spin_unlock(&ka->pvclock_gtod_sync_lock); >> >> if (vcpu->tsc_catchup) { >> u64 tsc = compute_guest_tsc(v, kernel_ns); >> if (tsc > tsc_timestamp) { >> adjust_tsc_offset_guest(v, tsc - tsc_timestamp); >> tsc_timestamp = tsc; >> } >> } >> >> And so when KVM skips the masterclock update after a TSC write, i.e. after >> a new TSC generation is started, the "kernel_ns-vcpu->arch.this_tsc_nsec" >> is *guaranteed* to generate a negative value, because this_tsc_nsec was >> captured after ka->master_kernel_ns. >> >> Forcing a masterclock update essentially fudged around that problem, but >> in a heavy handed way that introduced undesirable side effects, i.e. >> unnecessarily forces a masterclock update when a new vCPU joins the party >> via hotplug. >> >> Note, KVM forces masterclock updates in other weird ways that are also >> likely unnecessary, e.g. when establishing a new Xen shared info page and >> when userspace creates a brand new vCPU. But the Xen thing is firmly a >> separate mess, and there are no known userspace VMMs that utilize kvmclock >> *and* create new vCPUs after the VM is up and running. I.e. the other >> issues are future problems. >> >> Reported-by: Dongli Zhang <dongli.zhang@oracle.com> >> Closes: https://urldefense.com/v3/__https://lore.kernel.org/all/20230926230649.67852-1-dongli.zhang@oracle.com__;!!ACWV5N9M2RV99hQ!N3CdrL7gBde6tjlPxmd0cuqYCaVI4VGrvIqGX5I5pNx-cL_srMa6VuXUwrFXAA7nMgPXRvzndIOCkz-r1w$ >> Fixes: 7f187922ddf6 ("KVM: x86: update masterclock values on TSC writes") >> Cc: David Woodhouse <dwmw2@infradead.org> >> Signed-off-by: Sean Christopherson <seanjc@google.com> >> --- >> arch/x86/kvm/x86.c | 29 ++++++++++++++++------------- >> 1 file changed, 16 insertions(+), 13 deletions(-) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 530d4bc2259b..61bdb6c1d000 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -2510,26 +2510,29 @@ static inline int gtod_is_based_on_tsc(int mode) >> } >> #endif >> >> -static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) >> +static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation) >> { >> #ifdef CONFIG_X86_64 >> - bool vcpus_matched; >> struct kvm_arch *ka = &vcpu->kvm->arch; >> struct pvclock_gtod_data *gtod = &pvclock_gtod_data; >> >> - vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 == >> - atomic_read(&vcpu->kvm->online_vcpus)); >> + /* >> + * To use the masterclock, the host clocksource must be based on TSC >> + * and all vCPUs must have matching TSCs. Note, the count for matching >> + * vCPUs doesn't include the reference vCPU, hence "+1". >> + */ >> + bool use_master_clock = (ka->nr_vcpus_matched_tsc + 1 == >> + atomic_read(&vcpu->kvm->online_vcpus)) && >> + gtod_is_based_on_tsc(gtod->clock.vclock_mode); >> >> /* >> - * Once the masterclock is enabled, always perform request in >> - * order to update it. >> - * >> - * In order to enable masterclock, the host clocksource must be TSC >> - * and the vcpus need to have matched TSCs. When that happens, >> - * perform request to enable masterclock. >> + * Request a masterclock update if the masterclock needs to be toggled >> + * on/off, or when starting a new generation and the masterclock is >> + * enabled (compute_guest_tsc() requires the masterclock snapshot to be >> + * taken _after_ the new generation is created). >> */ >> - if (ka->use_master_clock || >> - (gtod_is_based_on_tsc(gtod->clock.vclock_mode) && vcpus_matched)) >> + if ((ka->use_master_clock && new_generation) || >> + (ka->use_master_clock != use_master_clock)) >> kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu); >> >> trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc, >> @@ -2706,7 +2709,7 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc, >> vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec; >> vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write; >> >> - kvm_track_tsc_matching(vcpu); >> + kvm_track_tsc_matching(vcpu, !matched); >> } >> >> static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value) >> >> base-commit: 437bba5ad2bba00c2056c896753a32edf80860cc
On Tue, Nov 14, 2023, Dongli Zhang wrote: > Hi Sean, > > Would mind sharing if the patch is waiting for Reviewed-by, and when it will be > merged into kvm-x86 tree? I'm at LPC this week, and out next week, so nothing is going to get applied to kvm-x86 until after -rc3. I considered trying to squeeze in a few things this week, but decided to just wait until -rc3 and not rush anything, as the timing doesn't really matter in the end. > While I not sure if the same developer can give both Tested-by and Reviewed-by ... > > Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com> Thanks! Providing both a Reviewed-by and Tested-by is totally valid.
On 14 November 2023 14:39:39 GMT-05:00, Sean Christopherson <seanjc@google.com> wrote:
> timing doesn't really matter in the end.
No pun intended?
On Wed, 18 Oct 2023 12:56:38 -0700, Sean Christopherson wrote: > Don't force a masterclock update when a vCPU synchronizes to the current > TSC generation, e.g. when userspace hotplugs a pre-created vCPU into the > VM. Unnecessarily updating the masterclock is undesirable as it can cause > kvmclock's time to jump, which is particularly painful on systems with a > stable TSC as kvmclock _should_ be fully reliable on such systems. > > The unexpected time jumps are due to differences in the TSC=>nanoseconds > conversion algorithms between kvmclock and the host's CLOCK_MONOTONIC_RAW > (the pvclock algorithm is inherently lossy). When updating the > masterclock, KVM refreshes the "base", i.e. moves the elapsed time since > the last update from the kvmclock/pvclock algorithm to the > CLOCK_MONOTONIC_RAW algorithm. Synchronizing kvmclock with > CLOCK_MONOTONIC_RAW is the lesser of evils when the TSC is unstable, but > adds no real value when the TSC is stable. > > [...] Applied to kvm-x86 misc, thanks! [1/1] KVM: x86: Don't unnecessarily force masterclock update on vCPU hotplug https://github.com/kvm-x86/linux/commit/c52ffadc65e2 -- https://github.com/kvm-x86/linux/tree/next
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 530d4bc2259b..61bdb6c1d000 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2510,26 +2510,29 @@ static inline int gtod_is_based_on_tsc(int mode) } #endif -static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) +static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation) { #ifdef CONFIG_X86_64 - bool vcpus_matched; struct kvm_arch *ka = &vcpu->kvm->arch; struct pvclock_gtod_data *gtod = &pvclock_gtod_data; - vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 == - atomic_read(&vcpu->kvm->online_vcpus)); + /* + * To use the masterclock, the host clocksource must be based on TSC + * and all vCPUs must have matching TSCs. Note, the count for matching + * vCPUs doesn't include the reference vCPU, hence "+1". + */ + bool use_master_clock = (ka->nr_vcpus_matched_tsc + 1 == + atomic_read(&vcpu->kvm->online_vcpus)) && + gtod_is_based_on_tsc(gtod->clock.vclock_mode); /* - * Once the masterclock is enabled, always perform request in - * order to update it. - * - * In order to enable masterclock, the host clocksource must be TSC - * and the vcpus need to have matched TSCs. When that happens, - * perform request to enable masterclock. + * Request a masterclock update if the masterclock needs to be toggled + * on/off, or when starting a new generation and the masterclock is + * enabled (compute_guest_tsc() requires the masterclock snapshot to be + * taken _after_ the new generation is created). */ - if (ka->use_master_clock || - (gtod_is_based_on_tsc(gtod->clock.vclock_mode) && vcpus_matched)) + if ((ka->use_master_clock && new_generation) || + (ka->use_master_clock != use_master_clock)) kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu); trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc, @@ -2706,7 +2709,7 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc, vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec; vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write; - kvm_track_tsc_matching(vcpu); + kvm_track_tsc_matching(vcpu, !matched); } static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)