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] softtsc for PV guests

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] softtsc for PV guests
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Sun, 23 Aug 2009 10:03:21 -0700
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 23 Aug 2009 10:03:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <549ae3d4-27e8-4689-8218-5e01261d2739@default>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <549ae3d4-27e8-4689-8218-5e01261d2739@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 08/23/09 09:42, Dan Magenheimer wrote:
> While I'm hoping that this is true, I am skeptical.  The
> PV time algorithm does depend on TSC accuracy for interpolating
> over short intervals doesn't it?

Yes, it extrapolates, assuming that in the absence of power events, etc,
the tsc is stable over a period of a few seconds on a given CPU.

> Assuming an SMP PV guest starts on a machine with "safe TSC" (e.g. a
> recent multi-core single-socket) and migrates successively to
> a sequence of machines with:
> 1) a multi-socket where TSCs are not synchronized and skew badly
> 2) a different multi-core single-socket with a faster TSC frequencey
> 3) a multi-core/socket where TSC frequency varies according to
>    per-cpu power-saving configuration
> does the SMP PV guest maintain time properly?

It uses timing parameters from Xen.  If Xen can't keep track of the tsc
and events which affect it and provides bad info, it will fail.  But
then it means that Xen can't use the tsc internally either, so
presumably won't be able to accurately emulate it either.  The ABI never
assumes that the tsc is synchronized between CPUs, or that they're
running at even approximately the same rate.

The main risk is having the CPU asynchronously change speed under Xen,
with either no notification or a delayed notification (like thermal
events).  Any synchronous speed change can be dealt with.

> And even if it does, this doesn't help applications that read
> TSC directly (which, admittedly, they shouldn't, but since
> the processor vendors have made TSC much "safer" on most
> systems, which will probably soon account for >90% of systems
> shipped, SMP app direct use of TSC will likely become more prevalent.)

Right.  That's basically not supported under Linux, except as part of
certain ABIs like vgettimeofday (which is functionally identical to the
Xen PV clock ABI).

> It's dom0.  I do see get an IP but it varies pretty widely from
> sample (of '0') to sample and I haven't tried a symbol lookup
> yet because I fear they will be buried in layers of block drivers
> I'm still hoping for some clue without digging that deep...
> All I've presumably done (assuming my patch doesn't have a weird
> bug) is make rdtsc slower.

It's presumed to be fast in a number of places, but it shouldn't cause
it to fail.  Maybe some race is coming up.  If you just revert the
register write to make rdtsc trap, does it still hang?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>