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. Also, the masterclock support has been in there for a while. It was not working as well as it could, which is why we noticed it only now, but still it was broken before as well. 1/5th of a jiffy is a really really low amount. >>> MSR_KVM_SYSTEM_TIME is deprecated -- we could remove it now, with >>> MSR_KVM_WALL_CLOCK (after hiding KVM_FEATURE_CLOCKSOURCE) if we want >>> to support old guests. >> >> 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". But it's just not how reality works, and it must show sooner or later. :) Anyway, it's just two case labels or so (before this patch). >> 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. Paolo -- 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
