RE: [xen-devel] System time monotonicity

["Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>]

Hi Keir,

 

Your suggestion below is a good one. I'll give it a try and let you know.

 

(I thought most systems did expose an hpet, at least modern ones.

All the systems I use expose it.

My code defaults back to the tsc way of doing things when no hpet is

detected.)

 

Regards,

Dave

---

From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Fri 4/11/2008 5:41 PM
To: Dave Winchell
Cc: dan.magenheimer@xxxxxxxxxx; Ian Pratt; Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [xen-devel] System time monotonicity

On 11/4/08 22:20, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> Its a fairly simple matter to base the hpet on the physical hpet. Its
>> easy to share it among guests
>> as no one really writes the physical hpet.  Offsets are kept in each
>> vhpet such that each guest thinks
>> he owns the hpet.
>
> This is really no better than basing on Xen system time. Actually it's worse
> since most systems don't even expose the HPET, so we can't probe it (without
> hacks) and so we can't use it. Xen's system time abstraction, perhaps with the
> max(last, curr) addition, is perfectly good enough.

Just to labour the point some more: If you still believe that diving to the
real platform timer on every guest time access is measurably more accurate,
you can cleanly prove that by building on Xen's system time abstraction, and
then switch between using get_s_time() (aka NOW()) and
read_platform_stime(). The latter calculates current system time by reading
from the platform timer *right now*. It's the function that all local CPUs
calibrate to once per second.

 -- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel