This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [xen-devel] System time monotonicity

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [xen-devel] System time monotonicity
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 9 Apr 2008 10:33:58 -0600
Delivery-date: Wed, 09 Apr 2008 09:34:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4229437.1EF6A%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > 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.


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