RE: [xen-devel] System time monotonicity

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

> > Let me clarify... unless my reading of the code is wrong, ALL hvm
> > guests that rely on ANY (virtual) platform timer are UNKNOWINGLY
> > relying on the physical TSCs.  Thus if the underlying physical
> > system has unsynchronized TSCs, different vcpus in an SMP HVM
> > guest (or even the SAME vcpu when rescheduled on another pcpu)
> > may find that consecutive reads of ANY (virtual) platform timer
> > are unexpectedly non-monotonic, which violates the whole purpose
> > of using a PLATFORM timer.
> 
> This is all true. The logic in vpt.c should be fixed to use 
> Xen's concept of
> system time and everything, guest TSC included, should be 
> derived from that.

Does Xen's concept of system time have sufficient resolution
and continuity to ensure both monotonicity and a reasonable
guest timer granularity?  I'm thinking not; some form of
interpolation will probably be necessary which will require
reading a physical platform timer** (e.g. other than tsc).

Since a guest that is presented with a (virtual) platform timer
of a given resolution may come to rely on both the monotonicity
AND resolution of that timer, I'm beginning to understand why
"that other virtualization company" doesn't virtualize HPET.

Dan

** Lest anyone say "well then just read the d**n platform timer",
be aware that it must be done judiciously as it can be very
expensive: On one recent vintage box I have, I measured reading
HPET at about 10000 cycles and reading PIT at about 50000!
So if every vcpu on every guest reads the (virtual) platform
timer at 1000Hz, things can get ugly fast.



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