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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
