RE: [PATCH 0/2] Improve hpet accuracy

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

> >> 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.

I fully agree.  That's why I think the default parameters in Xen
should "do the right thing".  The default will get the most
testing and if users say "time hurts when I change the parameters"
we can say "then don't change the parameters" ;-)

> In your example above, by synchronised TSC do you mean 
> constant-rate TSC?
> That can at least be hidden in CPUID now.

I meant synchronized as defined in 2.6.18/arch/x86_64/kernel/time.c
in the function unsynchronized_tsc() and as used in the same file
in time_init_gtod().  To make this more complicated, these routines
have had not-insignificant bug fixes in RHEL5u1/2.

But yes, it might be a good idea if X86_FEATURE_CONSTANT_TSC
always returns 0 (or at least is configurable and defaults off),
since the test may only be made in the guest at boot time and
the guest may migrate to a machine without the feature.

More ugliness, I know.  My head hurts.

Dan