On 2016-03-23 22:00, Paolo Bonzini wrote: > > > 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. This sounds to me like we should try to address the issue Yuki is seeing without playing with the nmi_pending counter. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- 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
