From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: guest gettimeofday behavior Date: Tue, 30 Jun 2009 09:54:29 +0300 Message-ID: <4A49B6A5.4090801@redhat.com> References: <4A4730B9.1090902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Eran Rom Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44982 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752647AbZF3GyY (ORCPT ); Tue, 30 Jun 2009 02:54:24 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 06/29/2009 10:11 PM, Eran Rom wrote: >> Nevertheless, the tsc clock is not reliable, >> the host can scale it, or >> go into >> deep sleep state. >> > indeed my current clock source is tsc > > You won't get accurate timing with tsc. >> So either use newer kernel with kvmclock (pv) >> or change the clock source >> into rtc/pit >> >> > No rtc/pit in my available clock sources, however, > I assume its a question of kernel compilation parameters, > is that right? > What is the advantage of rtc/pit/kvmclock (pv)over tsc? > They are accurate. > Also, is kvmclock (pv) better than the other two options. > Yes. > the thing is that I am 'confined' to use 2.6.27, > and if I decide on kvmclock, i will need to add it > 'manually' > 2.6.27 has kvmclock. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.