From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
Nobuo Yoshida <yoshida.nb@ncos.nec.co.jp>
Subject: Re: [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist
Date: Wed, 23 Mar 2016 20:04:07 +0100 [thread overview]
Message-ID: <20160323190406.GB22164@potion.brq.redhat.com> (raw)
In-Reply-To: <56F2DEDD.5060600@redhat.com>
2016-03-23 19:22+0100, Paolo Bonzini:
> On 23/03/2016 18:21, Radim Krčmář wrote:
>> NMIs are latched (queue length 1) and therefore cannot be pending after
>> an injection. I think we want to do it unconditionally.
>
> If that is right, process_nmi would be the place where you'd limit the
> queue to 1.
You are right.
I think we can always limit the queue to 1:
process_nmi is from 7460fb4a3400 ("KVM: Fix simultaneous NMIs") and the
commit message explains
If simultaneous NMIs happen, we're supposed to queue the second and
next (collapsing them), but currently we sometimes collapse the second
into the first.
I think that hardware coalesces all NMIs that arrive within one
instruction (NMI is delivered at instruction boundaries)
and one NMI is sufficient anyway (all events that triggered NMIs are
going to be handled in the first one and the second one is for nothing),
so reasons behind "supposed to" elude me.
We could overhaul NMI handling much more at that point, but it's safer
to keep it this way as there aren't major bugs. :)
next prev parent reply other threads:[~2016-03-23 19:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 5:08 [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist Yuki Shibuya
2016-03-23 13:18 ` Paolo Bonzini
2016-03-23 17:21 ` Radim Krčmář
2016-03-23 18:22 ` Paolo Bonzini
2016-03-23 19:04 ` Radim Krčmář [this message]
2016-03-23 21:00 ` Paolo Bonzini
2016-03-23 21:06 ` Jan Kiszka
2016-03-23 21:11 ` Paolo Bonzini
2016-03-23 21:55 ` Radim Krčmář
2016-03-24 5:08 ` Yuki Shibuya
2016-03-24 11:09 ` Paolo Bonzini
2016-03-23 21:52 ` Radim Krčmář
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=20160323190406.GB22164@potion.brq.redhat.com \
--to=rkrcmar@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shibuya.yk@ncos.nec.co.jp \
--cc=yoshida.nb@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