On Mon, Dec 07 2020 at 14:16, Vitaly Kuznetsov wrote:
> Maxim Levitsky <mlevitsk@xxxxxxxxxx> 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
