From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: System time monotonicity Date: Fri, 11 Apr 2008 16:05:32 -0600 Message-ID: <20080411160532015.00000002992@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 Cc: "Tian, Kevin" , "dan.magenheimer@oracle.com" , "xen-devel@lists.xensource.com" , Dave Winchell , Ian Pratt List-Id: xen-devel@lists.xenproject.org > If we wanted to be more certain we could maintain a = > last_system_time fields per VCPU and If you mean per VCPU *and* per guest this seems like a good idea. > backwards, by turning small backwards deltas into very short = > periods of stalled time. The stalled time may be a problem, but only if the tsc skew between processors is "bad". Your estimate of 100us seems like it could be unacceptable for some applications. Any idea how expensive arch/x86/time.c:local_time_calibration() is? If it's not too bad, one option might be to add a xen boot parameter "calibratehz" to calibrate more frequently. Then systems running time-sensitive guests can be instructed to increase the parameter accordingly to ensure tsc skew is small enough. > > If you are not confident that this will be OK on existing and > > (within-reason) future Xen platforms, perhaps the hvm virtual > > platform timers should (at least optionally) be built on physical > > platform timers (Dave Winchell cc'ed), which would ensure time > > never goes backwards. > = > If we wanted to be more certain we could maintain a = > last_system_time fields > per VCPU and, whenever using system time to compute current = > value for a > virtual timer for an HVM VCPU, we could actually use max(system time, > last_system_time). This would mean we were 100% sure that = > time didn't go > backwards, by turning small backwards deltas into very short = > periods of > stalled time. > = > As it is: no, since system time 'free runs' on each CPU over = > one-second > periods, there can be drift between CPUs if they are driven = > by different > oscillators. Also there are tolerances in our software = > calibration code to > consider. Which is why Linux guests implement the max(curr = > time, last time) > in their gettimeofday() code. It would be quite reasonable to = > the same, > inside Xen, for HVM guests. We can at least be pretty certain that any > drifts across CPUs/VCPUs will be on the order of less than 100us. > = > -- Keir > = > = >