From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Make QEmu HPET disabled by default for KVM? Date: Sun, 14 Mar 2010 12:27:04 +0200 Message-ID: <4B9CB9F8.6010205@redhat.com> References: <201003111552.54293.sheng@linux.intel.com> <4B98A294.7010104@redhat.com> <20100311190807.GD17264@amt.cnet> <4B9C8ACE.4090400@redhat.com> <20100314071038.GC19233@redhat.com> <4B9CB91D.3050708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Marcelo Tosatti , Sheng Yang , kvm@vger.kernel.org To: dlaor@redhat.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39645 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756715Ab0CNK1w (ORCPT ); Sun, 14 Mar 2010 06:27:52 -0400 In-Reply-To: <4B9CB91D.3050708@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/14/2010 12:23 PM, Dor Laor wrote: > On 03/14/2010 09:10 AM, Gleb Natapov wrote: >> On Sun, Mar 14, 2010 at 09:05:50AM +0200, Avi Kivity wrote: >>> On 03/11/2010 09:08 PM, Marcelo Tosatti wrote: >>>> >>>>> >>>>>> I have kept --no-hpet in my setup for >>>>>> months... >>>>> Any details about the problems? HPET is important to some guests. >>>> As Gleb mentioned in the other thread, reinjection will introduce >>>> another set of problems. >>>> >>>> Ideally all this timer related problems should be fixed by correlating >>>> timer interrupts and time source reads. >>> >>> This still needs reinjection (or slewing of the timer frequency). >>> Correlation doesn't fix drift. >>> >> But only when all time sources are synchronised and correlated with >> interrupts we can slew time frequency without guest noticing (and only >> if guest disables NTP) > > In the mean time we should definitely disable hpet by default. Definitely not. Windows needs it. Some pre-kvmclock Linux may also work with it. Without hpet, there is no fast high resolution timer in the system. > Besides this we need to fully virtualize the tsc, fix win7 64bit rtc > time drift and some pvclock potential issues. Before we add new timer, > better fix existing ones. > > What about creating a pv time keeping device that will be aware of > lost ticks and host wall clock time? It's similar to hyper-v > enlightenment virt timers. That's kvmclock. -- error compiling committee.c: too many arguments to function