Messages in this thread | | | Date | Wed, 14 Jul 2010 13:55:25 -0700 | Subject | Re: [patch 1/2] x86_64 page fault NMI-safe | From | Linus Torvalds <> |
| |
On Wed, Jul 14, 2010 at 1:17 PM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > It only handles the case of a single NMI coming in. What happens in this > scenario?
[ two nested NMI's ]
The _right_ thing happens.
What do you think the hardware would have done itself? The NMI was blocked. It wouldn't get replayed twice. If you have two NMI's happening while another NMI is active, you will get a single NMI after the first NMI has completed.
So stop these _idiotic_ complaints. And face the music:
- NMI's aren't that important. They are a _hell_ of a lot less important than the standard page fault path, for example.
- We do _not_ want to add more NMI magic outside of the NMI codepaths. It's much better to handle NMI special cases in the NMI code, rather than sprinkle them in random other codepaths (like percpu allocators) that have NOTHING WHAT-SO-EVER to do with NMI's!
Linus
> > - NMI (1) comes in. > - takes a fault > - iret > - NMI (2) comes in. > - nesting detected, popf/ret > - takes another fault > - NMI (3) comes in. > - nesting detected, popf/ret > - iret faults > - executes only one extra NMI handler > > We miss NMI (3) here. I think this is an important change from a semantic where, > AFAIK, the hardware should be allowed to assume that the CPU will execute as > many nmi handlers are there are NMIs acknowledged. > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > Operating System Efficiency R&D Consultant > EfficiOS Inc. > http://www.efficios.com > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |