kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v2 01/14] KVM: x86: change PIT discard tick policy
Date: Thu, 18 Feb 2016 17:56:08 +0100	[thread overview]
Message-ID: <20160218165608.GC18904@potion.brq.redhat.com> (raw)
In-Reply-To: <56C5EDA9.9030204@redhat.com>

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.)

  reply	other threads:[~2016-02-18 16:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17 19:14 [PATCH v2 00/14] KVM: x86: change PIT discard policy and untangle related code Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 01/14] KVM: x86: change PIT discard tick policy Radim Krčmář
2016-02-18 16:13   ` Paolo Bonzini
2016-02-18 16:56     ` Radim Krčmář [this message]
2016-02-18 17:33       ` Paolo Bonzini
2016-02-18 17:55         ` Paolo Bonzini
2016-02-19 14:44           ` Radim Krčmář
2016-02-25 12:34             ` Peter Krempa
2016-02-25 13:38             ` Paolo Bonzini
2016-02-25 17:36               ` Radim Krčmář
2016-02-25 19:11                 ` Paolo Bonzini
2016-02-26 13:44                   ` Radim Krčmář
2016-02-18 18:49   ` Paolo Bonzini
2016-02-17 19:14 ` [PATCH v2 02/14] KVM: x86: simplify atomics in kvm_pit_ack_irq Radim Krčmář
2016-02-18 18:04   ` Paolo Bonzini
2016-02-19 15:51     ` Radim Krčmář
2016-02-19 15:56       ` Paolo Bonzini
2016-02-17 19:14 ` [PATCH v2 03/14] KVM: x86: add kvm_pit_reset_reinject Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 04/14] KVM: x86: use atomic_t instead of pit.inject_lock Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 05/14] KVM: x86: tone down WARN_ON pit.state_lock Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 06/14] KVM: x86: pass struct kvm_pit instead of kvm in PIT Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 07/14] KVM: x86: remove unnecessary uses of PIT state lock Radim Krčmář
2016-02-18 18:03   ` Paolo Bonzini
2016-02-19 14:45     ` Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy Radim Krčmář
2016-02-18 18:05   ` Paolo Bonzini
2016-02-18 18:08   ` Paolo Bonzini
2016-02-19 15:04     ` Radim Krčmář
2016-02-19 15:06       ` Paolo Bonzini
2016-02-19 15:09         ` Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 09/14] KVM: x86: refactor kvm_create_pit Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 10/14] KVM: x86: refactor kvm_free_pit Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 11/14] KVM: x86: remove pit and kvm from kvm_kpit_state Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 12/14] KVM: x86: remove pointless dereference of PIT Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 13/14] KVM: x86: don't assume layout of kvm_kpit_state Radim Krčmář
2016-02-17 19:14 ` [PATCH v2 14/14] KVM: x86: move PIT timer function initialization Radim Krčmář
2016-02-18 18:11 ` [PATCH v2 00/14] KVM: x86: change PIT discard policy and untangle related code Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160218165608.GC18904@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=riel@redhat.com \
    --cc=shibuya.yk@ncos.nec.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).