WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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: Fri, 21 Aug 2009 16:31:05 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 21 Aug 2009 16:31:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A8F277A.7080103@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 15:17, Dan Magenheimer wrote:
> > I'm starting to play with implementing softtsc for
> > PV guests, but am not adequately familiar with the low
> > level x86 instruction set or emulation code in Xen.
> >
> > The attached patch seems to work fine for awhile.
> > Dom0 begins the boot process and the printk added
> > to traps.c observes more than 256K TSC traps (mostly
> > in the BogoMIPS calculation) and continues on loading
> > drivers etc but eventually freezes after:
> 
> The Xen clocksource uses rdtsc extensively for timing; emulating it
> would be a bad idea.  I guess it would make some sense to emulate
> usermode rdtsc, but it shouldn't affect kernel rdtscs.

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.  Full TSC emulation is done by
VMware and KVM is moving in that direction.

Lots more discussion needed here, will take it offline
(including a spark of a possible solution).

> > device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: 
> dm-devel@xxxxxxxxxx
> > kjournald starting.  Commit interval 5 seconds
> > EXT3-fs: mounted filesystem with ordered data mode.
> >
> > Any ideas on what might be stopping the dom0 boot?
> >   
> 
> How dead is the system?  Does it respond to sysrq-p?  'q' or 
> '0' on the Xen console?

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.

Interestingly, rdtsc continues to be emulated... the counter
output 512K and 1M and 2M, though it took well over an
hour to get to 2M.

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

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