RE: [Xen-devel] softtsc for PV guests

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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

Thanks,
Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel