2016-03-23 22:00+0100, Paolo Bonzini: > 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: Very nice, thanks! > 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. All NMI handlers are called now (nmi_handle) and it would be quite wrong to do otherwise, because NMIs do collapse in both models. > 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. Yes. :( > 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. I think that STI will keep the NMI latched (pending is a synonym) and that there is nothing between injected (recognized) and latched. APM (vol2, 15.21.5 Interrupt Shadows) says that interrupts aren't recognized during shadow. And that "The saved instruction pointer points to the instruction immediately following the boundary where the NMI was recognized." (vol2, 8.2.3 NMI—Non-Maskable-Interrupt Exception), so recognizing the NMI after STI would mean that we'd execute some instruction twice ... -- 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
