[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160218165608.GC18904@potion.brq.redhat.com>
Date: Thu, 18 Feb 2016 17:56:08 +0100
From: Radim Krčmář <rkrcmar@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Yuki Shibuya <shibuya.yk@...s.nec.co.jp>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH v2 01/14] KVM: x86: change PIT discard tick policy
2016-02-18 17:13+0100, Paolo Bonzini:
> On 17/02/2016 20:14, Radim Krčmář wrote:
>> 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.
>
> This seems like what libvirt calls the "merge" policy:
Oops, I never looked beyond QEMU after seeing that the naming in libvirt
doesn't even match ...
I think the policy that KVM implements (which I call discard) is "delay"
in libvirt. (https://libvirt.org/formatdomain.html#elementsTime)
>
> Merge the missed tick(s) into one tick and inject. The guest time
> may be delayed, depending on how the OS reacts to the merging of
> ticks
The "may be delayed" there makes me feel like the timer has to support a
guest visible counter of missed ticks.
PIT will definitely be delayed if we get another tick while the previous
one is still in IRR and there is nothing that the guest can do with it.
"catchup" is the other KVM policy and "discard" also needs to allow the
guest to handle lost ticks.
> where the merged tick is the one placed into IRR. Unlike discard,
> "merge" can starve the guest through an interrupt storm.
Yeah, starving a VCPU with an interrupt storm is more likely with the
changed policy. It's a pretty sad situation if all the time that VCPU
gets isn't even enough to run a PIT handler, so I didn't care.
The NMI watchdog bug can also be solved without changing the policy.
(It's a hack in any case.)
Powered by blists - more mailing lists