From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:55069 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757713AbcDLVTW (ORCPT ); Tue, 12 Apr 2016 17:19:22 -0400 Subject: Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy To: Greg Kroah-Hartman , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= References: <1460417015.25201.67.camel@decadent.org.uk> <20160412012135.GA11311@kroah.com> <20160412133023.GA3696@potion.brq.redhat.com> <20160412141313.GA7996@kroah.com> Cc: Ben Hutchings , Yuki Shibuya , stable From: Paolo Bonzini Message-ID: <570D6650.9080902@redhat.com> Date: Tue, 12 Apr 2016 23:19:12 +0200 MIME-Version: 1.0 In-Reply-To: <20160412141313.GA7996@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On 12/04/2016 16:13, Greg Kroah-Hartman wrote: > On Tue, Apr 12, 2016 at 03:30:23PM +0200, Radim Krčmář wrote: >> 2016-04-11 18:21-0700, Greg Kroah-Hartman: >>> On Tue, Apr 12, 2016 at 12:23:35AM +0100, Ben Hutchings wrote: >>>> On Wed, 2016-03-02 at 22:56 +0100, Radim Krčmář wrote: >>>>> Even though there is a chance of regressions, I think we can fix the >>>>> LVT0 NMI bug without introducing a new tick policy. >>>> [...] >>>> >>>> Given the 'chance of regressions', should we let this sit in mainline >>>> longer before including it in stable updates? >>> >>> Hm, good point, Radim, what do you think, is this good to go to stable >>> now? This has been in since 4.6-rc1, so it's been a few weeks with >>> people running it already... >> >> I think it is good to go. No reasonable workload should regress and the >> fixed use-case is common on old linux guest. >> >> This patch makes a difference if the guest doesn't EOI in PIT interrupts >> before the next one arrives. PIT would have been unreliable in that >> situation, so all worloads that that could regress have likely been >> avoided. Changes to NMI injection would need even crazier guest to >> regress. > > Ok, thanks, leaving it in. I agree. FWIW the behavior after the patch is consistent with what actual hardware does. The old behavior was _documented_ to be consistent with actual hardware, but instead it was crazy. Paolo