[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under Xen
> > 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |