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