On Mon, 26 Apr 2021 14:44:49 +0300 Maxim Levitsky <mlevitsk@xxxxxxxxxx> wrote: > On Mon, 2021-04-26 at 12:40 +0200, Paolo Bonzini wrote: > > On 26/04/21 11:33, Lai Jiangshan wrote: > > > When handle_interrupt_nmi_irqoff() is called, we may lose the > > > CPU-hidden-NMI-masked state due to IRET of #DB, #BP or other traps > > > between VMEXIT and handle_interrupt_nmi_irqoff(). > > > > > > But the NMI handler in the Linux kernel*expects* the CPU-hidden-NMI-masked > > > state is still set in the CPU for no nested NMI intruding into the beginning > > > of the handler. This is incorrect. The Linux kernel has for some time handled the case of nested NMIs. It had to, to implement the ftrace break point updates, as it would trigger an int3 in an NMI which would "unmask" the NMIs. It has also been a long time bug where a page fault could do the same (the reason you could never do a dump all tasks from NMI without triple faulting!). But that's been fixed a long time ago, and I even wrote an LWN article about it ;-) https://lwn.net/Articles/484932/ The NMI handler can handle the case of nested NMIs, and implements a software "latch" to remember that another NMI is to be executed, if there is a nested one. And it does so after the first one has finished. -- Steve
