From: Marcelo Tosatti <mtosatti@redhat.com>
To: kvm@vger.kernel.org
Cc: zamsden@gmail.com, joerg.roedel@amd.com,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: [patch 3/8] Leave TSC synchronization window open with each new sync
Date: Fri, 03 Feb 2012 15:43:52 -0200 [thread overview]
Message-ID: <20120203174449.045307765@amt.cnet> (raw)
In-Reply-To: 20120203174349.110232777@amt.cnet
[-- Attachment #1: 03-leave-tsc-sync-window-open.patch --]
[-- Type: text/plain, Size: 2415 bytes --]
From: Zachary Amsden <zamsden@gmail.com>
Currently, when the TSC is written by the guest, the variable
ns is updated to force the current write to appear to have taken
place at the time of the first write in this sync phase. This
leaves a cliff at the end of the match window where updates will
fall of the end. There are two scenarios where this can be a
problem in practe - first, on a system with a large number of
VCPUs, the sync period may last for an extended period of time.
The second way this can happen is if the VM reboots very rapidly
and we catch a VCPU TSC synchronization just around the edge.
We may be unaware of the reboot, and thus the first VCPU might
synchronize with an old set of the timer (at, say 0.97 seconds
ago, when first powered on). The second VCPU can come in 0.04
seconds later to try to synchronize, but it misses the window
because it is just over the threshold.
Instead, stop doing this artificial setback of the ns variable
and just update it with every write of the TSC.
It may be observed that doing so causes values computed by
compute_guest_tsc to diverge slightly across CPUs - note that
the last_tsc_ns and last_tsc_write variable are used here, and
now they last_tsc_ns will be different for each VCPU, reflecting
the actual time of the update.
However, compute_guest_tsc is used only for guests which already
have TSC stability issues, and further, note that the previous
patch has caused last_tsc_write to be incremented by the difference
in nanoseconds, converted back into guest cycles. As such, only
boundary rounding errors should be visible, which given the
resolution in nanoseconds, is going to only be a few cycles and
only visible in cross-CPU consistency tests. The problem can be
fixed by adding a new set of variables to track the start offset
and start write value for the current sync cycle.
Signed-off-by: Zachary Amsden <zamsden@gmail.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Index: kvm/arch/x86/kvm/x86.c
===================================================================
--- kvm.orig/arch/x86/kvm/x86.c
+++ kvm/arch/x86/kvm/x86.c
@@ -1053,7 +1053,6 @@ void kvm_write_tsc(struct kvm_vcpu *vcpu
offset = kvm_x86_ops->compute_tsc_offset(vcpu, data);
pr_debug("kvm: adjusted tsc offset by %llu\n", delta);
}
- ns = kvm->arch.last_tsc_nsec;
}
kvm->arch.last_tsc_nsec = ns;
kvm->arch.last_tsc_write = data;
next prev parent reply other threads:[~2012-02-03 17:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-03 17:43 [patch 0/8] KVM: Remaining body of TSC emulation work (Zachary Amsden) Marcelo Tosatti
2012-02-03 17:43 ` [patch 1/8] Infrastructure for software and hardware based TSC rate scaling Marcelo Tosatti
2012-02-08 14:28 ` Joerg Roedel
2012-02-03 17:43 ` [patch 2/8] Improve TSC offset matching Marcelo Tosatti
2012-02-03 17:43 ` Marcelo Tosatti [this message]
2012-02-03 17:43 ` [patch 4/8] Fix last_guest_tsc / tsc_offset semantics Marcelo Tosatti
2012-02-03 17:43 ` [patch 5/8] Add last_host_tsc tracking back to KVM Marcelo Tosatti
2012-02-03 17:43 ` [patch 6/8] Allow adjust_tsc_offset to be in host or guest cycles Marcelo Tosatti
2012-02-03 17:43 ` [patch 7/8] Dont mark TSC unstable due to S4 suspend Marcelo Tosatti
2012-02-08 15:18 ` Joerg Roedel
2012-02-08 15:56 ` Marcelo Tosatti
2012-02-09 14:28 ` Joerg Roedel
2012-02-03 17:43 ` [patch 8/8] Track TSC synchronization in generations Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120203174449.045307765@amt.cnet \
--to=mtosatti@redhat.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=zamsden@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox