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

["Radim Krčmář" <rkrcmar@redhat.com>]

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.