From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: kvmclock doesn't work, help? Date: Mon, 14 Dec 2015 14:44:15 +0100 Message-ID: <566EC7AF.3090508@redhat.com> References: <20151210213212.GA4836@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: kvm list , Radim Krcmar , X86 ML To: Andy Lutomirski , Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48098 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932348AbbLNNoW (ORCPT ); Mon, 14 Dec 2015 08:44:22 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 11/12/2015 22:57, Andy Lutomirski wrote: > I'm still not seeing the issue. > > The formula is: > > (((rdtsc - pvti->tsc_timestamp) * pvti->tsc_to_system_mul) >> > pvti->tsc_shift) + pvti->system_time > > Obviously, if you reset pvti->tsc_timestamp to the current tsc value > after suspend/resume, you would also need to update system_time. > > I don't see what this has to do with suspend/resume or with whether > the effective scale factor is greater than or less than one. The only > suspend/resume interaction I can see is that, if the host allows the > guest-observed TSC value to jump (which is arguably a bug, what that's > not important here), it needs to update pvti before resuming the > guest. Which is not an issue, since freezing obviously gets all CPUs out of guest mode. Marcelo, can you provide an example with made-up values for tsc and pvti? > Can you clarify concretely what goes wrong here? > > (I'm also at a bit of a loss as to why this needs both system_time and > tsc_timestamp. They're redundant in the sense that you could set > tsc_timestamp to zero and subtract (tsc_timestamp * tsc_to_system_mul) >> > tsc_shift to system_time without changing the result of the > calculation.) You would have to ensure that all elements of pvti are rounded correctly whenever the base TSC is updated. Doable, but it does seem simpler to keep subtract-TSC and add-nanoseconds separate. Paolo