Messages in this thread | | | Date | Tue, 20 Apr 2010 18:16:55 +0300 | From | Avi Kivity <> | Subject | Re: [PATCH 1/5] Add a global synchronization point for pvclock |
| |
On 04/20/2010 03:59 PM, Glauber Costa wrote: > >> Might be due to NMIs or SMIs interrupting the rdtsc(); ktime_get() >> operation which establishes the timeline. We could limit it by >> having a loop doing rdtsc(); ktime_get(); rdtsc(); and checking for >> some bound, but it isn't worthwhile (and will break nested >> virtualization for sure). Better to have the option to calibrate >> kvmclock just once on machines with >> X86_FEATURE_NONSTOP_TRULY_RELIABLE _TSC_HONESTLY. >> > For the record, we can only even do that in those machines. If we try to update > time structures only once in machines with the > X86_FEATURE_TSC_SAYS_IT_IS_OKAY_BUT_IN_REALITY_IS_NOT_OKAY feature flag, guests > won't even boot. > > We can detect that, and besides doing calculation only once, also export some > bit indicating that to the guest. Humm... I'm thinking now, that because of > migration, we should check this bit every time, because we might have changed host. > So instead of using an expensive cpuid check, we should probably use some bit in > the vcpu_time_info structure, and use a cpuid bit just to say it is enabled. >
Right, we need a bit in the structure itself that says you can trust the time not to go backwards, and a bit in cpuid that says you can trust the bit in the structure (unless we can be sure no implementations leak garbage into the padding field).
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
| |