Re: [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist

[Paolo Bonzini <pbonzini@redhat.com>]

On 23/03/2016 20:04, Radim Krčmář wrote:
> 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.

http://www.spinics.net/lists/kvm/msg61313.html provides the relevant
history lesson:

Jan: "Thinking this through again, it's actually not yet clear to me
what we are modeling here: If two NMI events arrive almost perfectly in
parallel, does the real hardware guarantee that they will always cause
two NMI events in the CPU? Then this is required."

Avi: "It's not 100% clear from the SDM, but this is what I understood
from it. And it's needed - the NMI handlers are now being reworked to
handle just one NMI source (hopefully the cheapest) in the handler, and
if we detect a back-to-back NMI, handle all possible NMI sources."

Not sure if that change actually ever happened in Linux (Avi went on
describing an application to pvspinlocks, but pvspinlocks ended up _not_
using NMIs), actually.

The Intel SDM is very obscure, AMD a bit less.  It says: "The processor
recognizes an NMI at an instruction boundary. [...] NMI cannot be
masked. However, when an NMI is recognized by the processor, recognition
of subsequent NMIs are disabled until an IRET instruction is executed."
Here recognition means delivery, acceptance need not be at instruction
boundaries (it can be at clock cycle boundary).  It might be possible to
figure this out on bare-metal by executing an expensive instruction such
as MFENCE.

There is also at least one case where you could have one pending (but
not injected) and one latched NMI at instruction boundary, and that is
the special NMI shadow from the STI instruction.

Paolo