Might be due to NMIs or SMIs interrupting the rdtsc(); ktime_get()For the record, we can only even do that in those machines. If we try to update
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.
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.