From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH v2 01/14] KVM: x86: change PIT discard tick policy Date: Thu, 18 Feb 2016 18:33:03 +0100 Message-ID: <56C6004F.2050105@redhat.com> References: <1455736496-374-1-git-send-email-rkrcmar@redhat.com> <1455736496-374-2-git-send-email-rkrcmar@redhat.com> <56C5EDA9.9030204@redhat.com> <20160218165608.GC18904@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yuki Shibuya , Rik van Riel To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: In-Reply-To: <20160218165608.GC18904@potion.brq.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 18/02/2016 17:56, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2016-02-18 17:13+0100, Paolo Bonzini: > > On 17/02/2016 20:14, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > > Discard policy uses ack_notifiers to prevent injection of PIT int= errupts > > > before EOI from the last one. > > >=20 > > > This patch changes the policy to always try to deliver the interr= upt, > > > which makes a difference when its vector is in ISR. > > > Old implementation would drop the interrupt, but proposed one inj= ects to > > > IRR, like real hardware would. > >=20 > > This seems like what libvirt calls the "merge" policy: >=20 > Oops, I never looked beyond QEMU after seeing that the naming in libv= irt > doesn't even match ... >=20 > I think the policy that KVM implements (which I call discard) is "del= ay" > in libvirt. (https://libvirt.org/formatdomain.html#elementsTime) Suppose the scheduled ticks are at times 0, 20, 40, 60, 80. The EOI fo= r time 0 is only delivered at time 42, other EOIs are timely. The resulting injections are: - for discard: 0, 60, 80. - for catchup, which QEMU calls slew: 0, 42, 51, 60, 80. - for merge: 0, 20 (in IRR, delivered at 42), 60, 80. =46or delay I *think* it would be 0, 42, 62, 82, 102. You know the i8254 code better than I do. Does this make sense to you? (Or in other words, does the code *really* do the above?...) > The "may be delayed" there makes me feel like the timer has to suppor= t a > guest visible counter of missed ticks. Yes, it depends whether the guest uses PIT to count time, or just to do periodic stuff (and then it reads the time from e.g. the PMTimer). In either case, only catchup ensures that time is not delayed, and it's used for Windows which uses the RTC periodic clock to count time. >> > 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 VCP= U > gets isn't even enough to run a PIT handler, so I didn't care. True. On one hand the hardware policy is clearly merge, not discard. The i8259 has an IRR! On the other hand I'm a bit wary of changing the policy without seeing exactly what the old OSes were doing in the PIT handler. > The NMI watchdog bug can also be solved without changing the policy. > (It's a hack in any case.) Can you send a patch for that? Paolo