All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Zachary Amsden <zamsden@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Avi Kivity <avi@redhat.com>, kvm <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [PATCH] fix kvmclock bug
Date: Tue, 28 Sep 2010 10:58:28 +0200	[thread overview]
Message-ID: <4CA1AE34.8080903@siemens.com> (raw)
In-Reply-To: <4CA0E9E0.7020209@redhat.com>

Am 27.09.2010 21:00, Zachary Amsden wrote:
> On 09/25/2010 11:54 PM, Jan Kiszka wrote:
>> That only leaves us with the likely wrong unstable declaration of the
>> TSC after resume. And that raises the question for me if KVM is actually
>> that much smarter than the Linux kernel in detecting TSC jumps. If
>> something is missing, can't we improve the kernel's detection mechanism
>> which already has suspend/resume support?
>>    
> 
> Linux must make the the conservative choice about TSC being declared
> unstable; if it is possible that it has become unstable, it is
> unstable.  Unfortunately, this bodes not well for us, as most of the
> finer points of accuracy depend on having a stable TSC.
> 
> There's a bunch of places that declare TSC unstable, and where in the
> suspend / resume cycle that happens would depend on your actual hardware.

It's absolutely clear where this happens: kvm_arch_vcpu_load. And it
seems to happen as the TSC is reset due to suspend-to-RAM.

Again: Linux recovers from this and continues to use the TSC. KVM is
more picky, so my question is if this is really required.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2010-09-28  8:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-19  0:15 [PATCH] fix kvmclock bug Zachary Amsden
2010-09-24  7:28 ` Jan Kiszka
2010-09-26  9:54   ` Jan Kiszka
2010-09-27 19:00     ` Zachary Amsden
2010-09-28  8:58       ` Jan Kiszka [this message]
2010-09-29  8:58 ` Avi Kivity

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=4CA1AE34.8080903@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=glommer@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=zamsden@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.