WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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