From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: What time is it kvm-clock? Date: Wed, 24 Feb 2016 20:44:43 +0100 Message-ID: <56CE082B.3020102@redhat.com> References: <56CDBAB1.6090405@redhat.com> <20160224173821.GA9364@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Owen Hofmann , KVM General , Peter Hornyack , Joao Martins To: Andy Lutomirski , Marcelo Tosatti Return-path: Received: from mail-wm0-f41.google.com ([74.125.82.41]:33217 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754406AbcBXTor (ORCPT ); Wed, 24 Feb 2016 14:44:47 -0500 Received: by mail-wm0-f41.google.com with SMTP id g62so3773414wme.0 for ; Wed, 24 Feb 2016 11:44:46 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 24/02/2016 20:38, Andy Lutomirski wrote: > If the master clock accurately exposed CLOCK_MONOTONIC_RAW or > CLOCK_MONOTONIC (I much prefer the latter), then it would be fine > across suspend/resume. Here we already have a conflict... Owen says he prefers the master clock to expose the (stable) TSC, you say you prefer CLOCK_MONOTONIC. I for one _thought_ CLOCK_MONOTONIC would have been my choice, but I'm not so sure about it and I'm also not sure it's possible to do it efficiently. The mult/shift/offset tuple potentially can change every tick, and it would be bad to do such an update #vms times per tick (or worse, #vcpus times per tick). Paolo