From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/2] Improve hpet accuracy Date: Mon, 09 Jun 2008 22:18:33 +0100 Message-ID: References: <20080609144837187.00000002776@djm-pc> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080609144837187.00000002776@djm-pc> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "dan.magenheimer@oracle.com" , Dave Winchell Cc: xen-devel , Ben Guthro List-Id: xen-devel@lists.xenproject.org On 9/6/08 21:48, "Dan Magenheimer" wrote: >> At guest install time you ought to be able to tell whether the guest >> will use hpet or not based on its version (RHELx, SLESy, Winz etc etc) >> and decide whether missed-ticks accounting is required or not. > > Unfortunately this is not true on Linux, at least without gathering > (and hardcoding) more information about the system. Whether hpet is > used or not is dependent not only on the OS/version and hvm config > parameters, but also on kernel command line parameters and even > the underlying CPU. For example, on RHEL5u1, if the tsc is synchronized > and the CPU is Intel, and no kernel parameters are chosen, tsc will be > chosen as the default clocksource even if hpet is present. Ugly. It's not immediately obvious that adding further independent configuration knobs to twiddle would make our lives that much easier. However it certainly increases the test matrix. In your example above, by synchronised TSC do you mean constant-rate TSC? That can at least be hidden in CPUID now. -- Keir