From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: Make QEmu HPET disabled by default for KVM? Date: Sun, 14 Mar 2010 14:51:08 +0200 Message-ID: <4B9CDBBC.3020900@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> <4B9CB9F8.6010205@redhat.com> Reply-To: dlaor@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: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41647 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756164Ab0CNMuJ (ORCPT ); Sun, 14 Mar 2010 08:50:09 -0400 In-Reply-To: <4B9CB9F8.6010205@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/14/2010 12:27 PM, Avi Kivity wrote: > 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. It's all depends on how hard would it be to re-inject to windows guest. We still need to fix the win2k3 64 bit and win2k8 64 bit (and not win7 as I told initially) since the irq is broadcasted to all the vcpus and we do not track who acknowledged the irq. > >> 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. > I meant a device that can be used to generate timeouts. We do use today pit/rtc along with kvmclock time source but it's not perfect and probably the same for hpet. This is why I tough that a pv device will be beneficial.