From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: kvmclock doesn't work, help? Date: Wed, 16 Dec 2015 10:17:16 -0800 Message-ID: References: <20151210213212.GA4836@amt.cnet> <566EC7AF.3090508@redhat.com> <20151214220027.GA24973@amt.cnet> <566FD25C.5040806@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Marcelo Tosatti , kvm list , Radim Krcmar , X86 ML To: Paolo Bonzini Return-path: Received: from mail-ob0-f178.google.com ([209.85.214.178]:36673 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755029AbbLPSRh (ORCPT ); Wed, 16 Dec 2015 13:17:37 -0500 Received: by mail-ob0-f178.google.com with SMTP id no2so38683881obc.3 for ; Wed, 16 Dec 2015 10:17:36 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Dec 16, 2015 at 9:48 AM, Andy Lutomirski wrote: > On Tue, Dec 15, 2015 at 12:42 AM, Paolo Bonzini wrote: >> >> >> On 14/12/2015 23:31, Andy Lutomirski wrote: >>> > RAW TSC NTP corrected TSC >>> > t0 10 10 >>> > t1 20 19.99 >>> > t2 30 29.98 >>> > t3 40 39.97 >>> > t4 50 49.96 >>> > >>> > ... >>> > >>> > if you suddenly switch from RAW TSC to NTP corrected TSC, >>> > you can see what will happen. >>> >>> Sure, but why would you ever switch from one to the other? >> >> The guest uses the raw TSC and systemtime = 0 until suspend. After >> resume, the TSC certainly increases at the same rate as before, but the >> raw TSC restarted counting from 0 and systemtime has increased slower >> than the guest kvmclock. > > Wait, are we talking about the host's NTP or the guest's NTP? > > If it's the host's, then wouldn't systemtime be reset after resume to > the NTP corrected value? If so, the guest wouldn't see time go > backwards. > > If it's the guest's, then the guest's NTP correction is applied on top > of kvmclock, and this shouldn't matter. > > I still feel like I'm missing something very basic here. > OK, I think I get it. Marcelo, I thought that kvmclock was supposed to propagate the host's correction to the guest. If it did, indeed, propagate the correction then, after resume, the host's new system_time would match the guest's idea of it (after accounting for the guest's long nap), and I don't think there would be a problem. That being said, I can't find the code in the masterclock stuff that would actually do this. If, on the other hand, the host's NTP correction is not supposed to propagate to the guest, then shouldn't KVM just update system_time on resume to whatever the guest would think it had (which I think would be equivalent to the host's CLOCK_MONOTONIC_RAW value, possibly shifted by some per-guest constant offset). --Andy