RE: [Xen-devel] [PATCH] TSC scaling for live migration between platforms with different TSC frequecies

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

This is a real virtualization problem.  Some apps
may use TSC as a monotonically increasing "sequence
number" to mark transactions.  For these apps,
TSC scaling is irrelevant (as long as the transition
doesn't cause the TSC to stop or go backwards).
Other apps (and/or the OS kernel) may use TSC to
approximate the passage of time, and for these apps
(and gettimeofday in the Linux kernel), this TSC scaling
patch is a must.  Unfortunately, both kinds of apps could
be running simultaneously on the same guest.  And
in either case, RDTSC frequency may be quite high.

I think a key missing fact is the overhead measurement
for trapping RDTSC.  I think someone at Intel measured
this once and it was quite bad.  Perhaps a better
question is:  If it is important to ALWAYS emulate RDTSC,
can the Xen code be written to handle RDTSC emulation
much faster?  If it could be made fast enough, the
proper default might best be always emulate (even
for PV guests... which also points out the fact that the
proposed patch only fixes HVM guests).

> -----Original Message-----
> From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx]
> Sent: Thursday, June 18, 2009 4:56 AM
> To: Zhang, Xiantao; Keir Fraser
> Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] TSC scaling for live 
> migration between
> platforms with different TSC frequecies
> 
> 
> >     This patchset targets for enabling TSC scaling in 
> software for live
> > migration between platforms with different TSC frequecies.  
> Once found the
> > target host's frequency is different with source host's, 
> hypervisor will
> > trap and emulate guest's all rdtsc instructions with its expected
> > frequency.
> >     If hardware's TSC frequency is difffernt with guest's 
> exepcted freq,
> > guest may behave abnormally, eg. incorrect wallclock, soft 
> lockup, even
> > hang in some cases.  Therefore, this patchset is necessary 
> to avoid such
> > issues.
> > 
> > PATCH 0001-- Save guest's preferred TSC in image for 
> save/restore and
> > migration PATCH 0002-- Move multidiv64 as a library function.
> > PATCH 0003-- Scaling host TSC freqeuncy patch.
> 
> I think this needs to be a feature which is enabled/disabled 
> on a per VM basis (in the config file).
> 
> I'm not sure what the default should be. Windows VMs and 
> applications don't seem to much care about the TSC which is 
> an argument for leaving the default as it is at the moment. 
> However, one could argue that things that don't care about 
> the TSC aren't going to be reading it much, so the overhead 
> of making the default to scale the TSC shouldn't be too high.
> 
> Ian
> 
> 
> 
> _______________________________________________
> 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