On Mon, Dec 07 2020 at 14:16, Vitaly Kuznetsov wrote:
Maxim Levitsky mlevitsk@redhat.com writes:
But other than that I don't mind making TSC offset global per VM thing. Paulo, what do you think about this?
Not Paolo here but personally I'd very much prefer we go this route but unsynchronized TSCs are, unfortunately, still a thing: I was observing it on an AMD Epyc server just a couple years ago (cured with firmware update).
Right this happens still occasionally, but for quite some time this is 100% firmware sillyness and not a fundamental property of the hardware anymore. Interestingly enough has the number of reports on Intel based systems vs. such wreckage as obvservable via TSC_ADJUST gone down after we added support for it and yelled prominently. I wish AMD would have that as well.
We try to catch such situation in KVM instead of blowing up but this may still result in subtle bugs I believe. Maybe we would be better off killing all VMs in case TSC ever gets unsynced (by default).
I just ran a guest on an old machine with unsynchronized TSCs and was able to observe clock monotonic going backwards between two threads pinned on two vCPUs, which _is_ bad. Getting unsynced clocks reliably under control is extremly hard.
Another thing to this bucket is kvmclock which is currently per-cpu. If we forbid TSC to un-synchronize (he-he), there is no point in doing that. We can as well use e.g. Hyper-V TSC page method which is per-VM. Creating another PV clock in KVM may be a hard sell as all modern x86 CPUs support TSC scaling (in addition to TSC offsetting which is there for a long time) and when it's there we don't really need a PV clock to make migration possible.
That should be the long term goal.
Thanks,
tglx