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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] softtsc for PV guests
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Sun, 23 Aug 2009 09:42:31 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 23 Aug 2009 09:43:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A8F34FE.6040602@xxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> On 08/21/09 16:31, Dan Magenheimer wrote:
> > Enabling CR4_TSD only traps ring>0 rdtscs.  Trapping guest kernel
> > rdtsc's is ultimately necessary because the Linux kernel does NOT
> > adequately handle all the possible changes in TSC characteristics
> > that can occur if Xen moves an already booted guest from one
> > physical machine to another (or even from one set of pcpus
> > to another on certain physical machines).  I recognize this
> > is very ugly, but it may be the only way to guarantee
> > correctness 100% of the time.
> PV guests already correct for that by using the data Xen 
> provides; they
> don't require Xen to do any correction or synthesis of tsc values.

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?

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?

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.)

> > The system is definitely not dead, but dom0 is busy looping or
> > something.  I can probably isolate the code, but the xen
> > changes seem small enough that it's hard to believe they
> > could cause this kind of problem.
> '0' on the Xen console will tell you where its spinning.  Oh, 
> is it dom0 or domU?

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.


Xen-devel mailing list

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