[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] softtsc for PV guests



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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.