RE: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under Xen

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > Isn't the real problem that, in a PV guest, the cpuid instructions
> > that are testing the TSC-related CPUID bits are obtaining the actual
> > hardware value, rather than what Xen would like the guest to believe?
> 
> No, because there shouldn't be any "naked" rdtscs in the kernel.
> 
> > IOW, isn't the correct fix to use pvcpuid instead of cpuid when
> > xen_pvdomain() is true?
> 
> Every use of cpuid in the kernel goes via the cpuid pvop, which ends up
> doing the Xen cpuid rather than the native one.  Usermode cpuid is
> still the "real" one, unless they explicitly use the Xen version.

OK, then I'm confused.  Either:
- this is one of those recent Intel boxes where all the TSCs should
  be sync'ed but due to firmware issues they are not, in which case
  this is a Linux bug that has already been fixed upstream; or
- this isn't Xen 4.0+ but should be fixed in 4.0; or
- this is Xen 4.0+ and the default tsc_mode is being overridden

Otherwise, why is TSC not synchronized and pvclock always getting
an offset of 0?

Apologies if this was stated in a differently titled thread
of this conversation but, Jed, what is your Xen version?

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