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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
