Re: KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue

Radim Krčmář
2015-01-22T17:02:10Z

2015-01-22 09:10+0100, Paolo Bonzini:
> On 21/01/2015 18:00, Radim Krčmář wrote:
> > 2015-01-21 12:16-0200, Marcelo Tosatti:
> >> On Wed, Jan 21, 2015 at 03:09:27PM +0100, Radim Krčmář wrote:
> >>> 2015-01-20 15:54-0200, Marcelo Tosatti:
> >>>> SuSE's 2.6.16 kernel fails to boot if the delta between tsc_timestamp
> >>>> and rdtsc is larger than a given threshold:
> >>> [...]
> >>>> Disable masterclock support (which increases said delta) in case the
> >>>> boot vcpu does not use MSR_KVM_SYSTEM_TIME_NEW.
> >>>
> >>> Why do we care about 2.6.16 bugs in upstream KVM?
> >>
> >> Because people do use 2.6.16 guests.
> >
> > (Those people probably won't use 3.19+ host ...
>
> Why not? If you are a cloud provider, you cannot really know what guests
> your customer run.

People running decade old kernels are likely conservative and changing
the host is unsafe too. (This bug was introduced later.)
I doubt they would risk VMs on a cloud that doesn't ensure stability.

(It's a weak reason, I should have argued that the buggy guest code
wasn't in Linux 2.6.16 and probably only dwells in a distribution whose
general support ended on 2013-07-31.)

> >> What is the benefit of removing support for MSR_KVM_SYSTEM_TIME ?
> >
> > The maintainability of the code increases. It would look as if we never
> > made the mistake with MSR_KVM_SYSTEM_TIME & MSR_KVM_WALL_CLOCK.
> > (I like when old code looks as if we wrote it from scratch.)
>
> Everybody does, and everybody obsesses over splitting patches so that
> they look as if the code had been split that way from scratch. Heck, I
> probably spend over half of my development time inside "git rebase -i".

(+ most of the rest is verification and testing :)

> But it's just not how reality works, and it must show sooner or later.

(Yeah, I am keenly observing and trying the predict the outcome.)

> >> Supporting old guests is important.
> >
> > It comes at a price.
> > (Mutually exclusive goals are important as well.)
>
> Marcelo's patch is not too high a price. Is it ugly? Yes. Could it be
> any better? No, because the ugliness is not his fault, it's intrinsic
> in the problem it solves.

Agreed, I've learned the circumstances that make it the best solution.
(I didn't acknowledge it as a problem and documentation states that
KVM_FEATURE_CLOCKSOURCE "may be removed in the future".
The the-future in the future.)

Thanks to you and Marcelo.