qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>
Cc: Gleb Natapov <gleb@kernel.org>, Will Auld <will.auld@intel.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] target-i386: clear guest TSC on reset
Date: Thu, 05 Dec 2013 14:53:05 +0100	[thread overview]
Message-ID: <52A08541.6090702@redhat.com> (raw)
In-Reply-To: <52A07C5A.9090105@lab.ntt.co.jp>

Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
>          /*
>           * KVM is yet unable to synchronize TSC values of multiple VCPUs on
>           * writeback. Until this is fixed, we only write the offset to SMP
>           * guests after migration, desynchronizing the VCPUs, but avoiding
>           * huge jump-backs that would occur without any writeback at all.
>           */
> -        if (smp_cpus == 1 || env->tsc != 0) {
> +        if (smp_cpus == 1 || env->tsc != 0 || level == KVM_PUT_RESET_STATE) {
>              kvm_msr_entry_set(&msrs[n++], MSR_IA32_TSC, env->tsc);
>          }

This is still a bit ugly, and desynchronizes the VCPUs on reset.

The main point of my outlined solution is that you only have one value
that is tracked, not one per VCPU (which in the case of migration adds
unpredictable latencies---for example due to emptying the migration
buffers).  We already save that value; all that's left is to use it
instead of env->tsc.

Though you would need one change here:

> - add a function kvm_set_ticks(int64_t ticks) to kvm-all.c and
> kvm-stub.c.  For kvm-all.c it calls kvm_arch_set_ticks(CPUState *cpu,
> int64_t ticks) in target-*/kvm.c.  The kvm_arch_set_tsc() function has a
> dummy implementation for all architectures except x86.  For x86 it calls
> KVM_SET_MSRS passing "ticks + env->tsc_offset". 

Instead you can make kvm_{,arch_}update_ticks() and pass
"cpu_get_ticks() + env->tsc_offset" to KVM_SET_MSRS (looping across all
VCPUs).  Assuming the TSC is synchronized to begin with on host CPUs,
and the latency is similar for all CPUs from the invocation of the ioctl
to the time TSC_OFFSET is written, the synchronization should be decent.

Paolo

  reply	other threads:[~2013-12-05 13:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1386054500.25757.10.camel@nexus>
     [not found] ` <529D90A6.2080801@lab.ntt.co.jp>
2013-12-05  6:08   ` [Qemu-devel] [PATCH] kvm: clear guest TSC on reset Fernando Luis Vázquez Cao
2013-12-05  6:15     ` [Qemu-devel] [PATCH] target-i386: " Fernando Luis Vázquez Cao
2013-12-05  9:28       ` Paolo Bonzini
2013-12-05 13:15         ` Fernando Luis Vazquez Cao
2013-12-05 13:53           ` Paolo Bonzini [this message]
2013-12-05 15:42             ` Fernando Luis Vazquez Cao
2013-12-05 16:02               ` Paolo Bonzini
2013-12-05 16:40                 ` Marcelo Tosatti
2013-12-05 17:06                   ` Marcelo Tosatti
2013-12-05 16:17               ` Marcelo Tosatti
2013-12-05 16:38                 ` Paolo Bonzini
2013-12-06  8:24                   ` Fernando Luis Vázquez Cao
2013-12-06  8:33                     ` [Qemu-devel] [PATCH 1//2 v3] " Fernando Luis Vázquez Cao
2013-12-06  8:38                       ` [Qemu-devel] [PATCH 2/2] target-i386: do not special case TSC writeback Fernando Luis Vázquez Cao
2013-12-06  8:36                     ` [Qemu-devel] [PATCH] target-i386: clear guest TSC on reset Paolo Bonzini
2013-12-06  8:56                       ` Fernando Luis Vázquez Cao
2013-12-06  9:08                         ` Paolo Bonzini
2013-12-06  9:20                           ` Fernando Luis Vazquez Cao
2013-12-06 14:22                     ` Marcelo Tosatti
2013-12-09  8:50                       ` Fernando Luis Vázquez Cao
2013-12-12  2:52                         ` Fernando Luis Vázquez Cao
2013-12-12 12:18                           ` Paolo Bonzini
2013-12-05 16:12         ` Marcelo Tosatti
2013-12-05 16:32           ` Paolo Bonzini

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=52A08541.6090702@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=fernando_b1@lab.ntt.co.jp \
    --cc=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=will.auld@intel.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;
as well as URLs for NNTP newsgroup(s).