| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home