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


[Xen-devel] Re: Large system boot problems

To: Bill Burns <bburns@xxxxxxxxxx>
Subject: [Xen-devel] Re: Large system boot problems
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 12 Feb 2008 16:54:31 +0000
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Carb, Brian A" <Brian.Carb@xxxxxxxxxx>
Delivery-date: Tue, 12 Feb 2008 08:55:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47B1CA9D.4000006@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achtl+/BLlR4dtmLEdyiyAAX8io7RQ==
Thread-topic: Large system boot problems
User-agent: Microsoft-Entourage/
On 12/2/08 16:34, "Bill Burns" <bburns@xxxxxxxxxx> wrote:

> Making this one line change, as in the attached patch
> yields a properly working dom0. Tested on both a small
> memory and large memory system.

It's not really correct though. The idea of the calibration algorithm is to
find a multiplier d(system_time)/d(tsc) which we can use to calculate
system_time deltas from tsc deltas by a simple multiplication.

The tsc_shift is effectively the exponent part of a custom floating-point
format (that mantissa part being calibration_mul_frac). The idea is to shift
tsc_elapsed such that stime_elapsed/tsc_elapsed yields a fraction between
0.5 and 1, and therefore maximises significant bits in the mantissa
representation which has an implicit leading radix point.

*So*, the upshot of all this is that when we shift stime_elapsed and
tsc_elapsed together, we do not change the value of
d(delta_stime)/d(delta_tsc) and so of course the exponent of that value
(tsc_shift) does not change.

Put another way, you've perturbed the system and coincidentally made the bug
go into hiding. But it's not really fixed and, in fact, your patch is simply
broken from an algorithmic point of view.

 -- Keir

Xen-devel mailing list