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: Fri, 21 Aug 2009 16:38:59 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 21 Aug 2009 16:39:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <dd256b18-7a63-4a4d-93fb-7c6208d2aeab@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Oops, got carried away discussing the general problem
rather than the specific one... :-)

At this point, I just want to trap all rdtsc's
so that I can measure how bad trapping is.
But I can't do that if dom0 (and/or a PV guest)
won't boot.

> -----Original Message-----
> From: Dan Magenheimer 
> Sent: Friday, August 21, 2009 5:31 PM
> To: Jeremy Fitzhardinge
> Cc: Xen-Devel (E-mail)
> Subject: RE: [Xen-devel] softtsc for PV guests
> > 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

Xen-devel mailing list

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