RE: [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please)

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

Hi Kevin --

> constant_tsc is one of the factors affecting tsc stability, and
> the keypoint is that one internal variable 'tsc_unstable' is
> initialized to zero. That means, kernel considers TSC as
> stable by default, and you need trigger some factors upon
> which guest kernel'd like to mark tsc as unstable when
> checking them. However by far none of those factors seem
> appliable to all circumstances.
>
> For example, even by hidding constant_tsc bit from cpuid,
> UP guest will still consider tsc as stable, and so does 32bit
> SMP guest running on Intel processors.

Yes, looking over some Linux code, I see you are right.  In
one version of RH, if the processor vendor is Intel, it
always assumes tsc is stable!

> Since it's 'if', we should treat it as an option, instead of 'NEVER',
> right? User may not have migration requirement in some cases,
> and or the migratable backups are with same bits exactly... :-)

Yes, if it could be done, I agree an option would be better
than 'NEVER'.  But Keir is not too keen on more time-related
options.

> >2) I *think* that in some cases even within the same system,
> >   TSC values will skew somewhat.  Since a uniprocessor guest
> >   will often be rescheduled to a different pcpu by Xen,
> >   the underlying tsc may appear erratic.
>
> Can't be the tsc kept monotonic to guest, with some tweak on
> tsc offset? Also Xen is always trying to sync tsc among cores.
> As long as you don't run on a box with multiple bus crystals,
> or a box without constant tsc upon freq change, the tsc drift
> among cores should be negligible considering the overhead of
> migration. Then for cases out of 'as long as', we should mark
> TSC as unstable, still as an option.

No Xen doesn't actally sync the tsc's, just maintains its own
software offset variables.  I suppose it could periodically check
to make sure the tsc skew is within some reasonable value,
but after the guest boots, it is probably too late.

> I vaguely recalled some posts about CPUID virtualization
> framework. There's no need to a seperate category, and it
> looks like this option can be aligned with that part?

Yes, good point.  I wasn't following that closely either but
this could be covered by it.

> >Another alternative would be to trap all rdtsc's and emulate
> >them but this probably will not be easy and may have
> >significant performance implications.  But perhaps it should
> >be an option?
>
> Agree.

Is this something that you (or Intel in general) could look at?
I would be happy to participate but I don't think I understand
VT well enough.  Once the trap occurs, I suppose Xen system time
could be used as the virtual TSC, possibly scaled up.

Thanks,
Dan

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