From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] strictly increasing hvm guest time Date: Wed, 2 Jul 2008 15:50:52 -0600 Message-ID: <20080702155052500.00000003744@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "Xen-Devel (E-mail)" Cc: Dave Winchell List-Id: xen-devel@lists.xenproject.org > > This simple one-line patch changes hvm guest time from > > monotonically non-decreasing to monotonically strictly- > > increasing. As a result, two consecutive reads of the > > (virtual) hpet will never return the same value, thus > > avoiding the appearance that time has stopped (which may > > occur if there is skew between physical processor TSCs). > = > It does seem a little hack-ish, if we don't know of any = > issues arising from > the current code, and we expect cross-cpu deltas to be pretty = > small. Using "xm debug-key t; xm dmesg | tail -1" you can get an idea of the deltas. Even on my single-socket dual-core recent-vintage Intel box, I'm frequently seeing Diff's > 300ns. While this is still relatively small (and part of it may be SMP cache synchronization time), this is supposed to be a "good TSC" box. I'm spinning a small patch capturing the maximum so that can be output via debug-key t also. > Also > guests will often convert HPET reads to well-known units (e.g., > microseconds, milliseconds) before using them, in which case = > even a delta of > one may not result in differing converted time values. Yes, but most newer Linux systems have a high-res timer API that returns nanoseconds, though admittedly it is not widely used yet. Thanks, Dan