Messages in this thread | | | Subject | Re: [RFC][PATCH 3/3] x86: Add workaround to NMI iret woes | From | Steven Rostedt <> | Date | Fri, 09 Dec 2011 10:00:28 -0500 |
| |
On Fri, 2011-12-09 at 10:22 +0100, Peter Zijlstra wrote:
> Its was definitely tongue in cheek, also I did say this'll be a massive > pain with paravirt since I doubt paravirt calls are NMI safe.
But does paravirt simulate NMIs? Does a guest ever take an NMI? I can enable paravirt to see if it breaks.
> > But yeah, it might all be slightly less painful than trying to teach the > INT3 handler about this recursion.
That's my goal. Yes, I agree this is all just an ugly hack, but I'm trying hard to keep the ugly hack contained in the NMI handling. Once you start letting this hack spread, it will grow like a virus, and resistance will be futile. And we will end up with nasty dependencies that will become a horror show to maintain.
Right now, I've quarantined the NMI code, and I'm keeping the infection at bay. The NMI code will grow warts and nasty appendages, but the NMI code was ugly to begin with, and maybe these mutations might even make it prettier. That's the nature of NMI. It's an ugly beast in all its incarnations.
This is why I like my patches. It contains the damage to only the NMI code. If something breaks from this code, it will be easy to find it. If anything, a bisect should show exactly what caused change caused the problem. But if we add hacks in other places, it will be much more difficult to figure out.
> > This all started with wanting to do pagefaults from NMI context, those > too will have this recursion, although for faults we'll end up in the > double fault handler, which seems to allow a slightly saner way out.
It didn't start with the pagefaults. That discussion only brought the issue to LKML. This has been a pain in our side or breakpoints from day one.
-- Steve
| |