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