Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy

Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

On Wed, 2016-03-02 at 22:56 +0100, Radim Krčmář wrote:
> From: Radim Krčmář <rkrcmar@redhat.com>
> 
> commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 upstream.
> 
> Discard policy uses ack_notifiers to prevent injection of PIT interrupts
> before EOI from the last one.
> 
> This patch changes the policy to always try to deliver the interrupt,
> which makes a difference when its vector is in ISR.
> Old implementation would drop the interrupt, but proposed one injects to
> IRR, like real hardware would.
> 
> The old policy breaks legacy NMI watchdogs, where PIT is used through
> virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
> thus a guest deadlock with disabled interrupts will stop NMIs.
> 
> Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
> through IOAPIC.  (KVM's PIT is deeply rotten and luckily not used much
> in modern systems.)
> 
> 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?

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy

[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:
> > From: Radim Krčmář <rkrcmar@redhat.com>
> > 
> > commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 upstream.
> > 
> > Discard policy uses ack_notifiers to prevent injection of PIT interrupts
> > before EOI from the last one.
> > 
> > This patch changes the policy to always try to deliver the interrupt,
> > which makes a difference when its vector is in ISR.
> > Old implementation would drop the interrupt, but proposed one injects to
> > IRR, like real hardware would.
> > 
> > The old policy breaks legacy NMI watchdogs, where PIT is used through
> > virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
> > thus a guest deadlock with disabled interrupts will stop NMIs.
> > 
> > Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
> > through IOAPIC.  (KVM's PIT is deeply rotten and luckily not used much
> > in modern systems.)
> > 
> > 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...

thanks,

greg k-h

Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy

[Radim Krčmář]

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.

(This patch always injects NMI from PIT and shrinks a window where a
 maskable PIT interrupt is discarded.  Previously, next interrupt would
 have been discarded as long as the last one is in IRR or ISR.  Only IRR
 is considered after this patch, so PIT interrupts are more likely to
 chain.)

Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy

[Greg Kroah-Hartman]

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.

greg k-h

Re: [PATCH 4.5 007/238] KVM: i8254: change PIT discard tick policy

[Paolo Bonzini]

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