Re: [RFC][PATCH 3/3] x86: Add workaround to NMI iret woes

[Jason Baron]

On Thu, Dec 08, 2011 at 09:43:36PM -0500, Steven Rostedt wrote:
> On Thu, 2011-12-08 at 14:36 -0500, Steven Rostedt wrote:
> 
> > I'm not sure how to handle this case. We could do something similar in
> > the break point code to handle the same thing. But this just seems
> > really ugly.
> > 
> > Anyone with any better ideas?
> 
> On IRC, Peter Zijlstra mentioned changing the IDT in NMI. I'm not sure
> if he was joking or not. But I decided to try it out. It seems to
> work :)
> 
> 
> What's nice is that this change is in the C code, which makes things
> much easier.
> 
> I check on nmi entry, if the nmi preempted code running with the debug
> stack. If it has, then I load a special "nmi_idt_table" that has a zero
> IST for the debug stack, which will make the debug interrupt in the NMI
> not change the stack pointer. Then on exit, it returns it to the old IDT
> table.
> 
> Just to see how bad this was, I made it make the change on every NMI. I
> didn't notice any difference, but I wasn't doing any real benchmark,
> except doing a perf top -c 1000.
> 
> But in practice, it should seldom hit, if ever. It only updates the IDT
> if it interrupted debug processing.
> 

Then, I'm wondering if the same technique can be used for the original
nmi->int3->nmi case. That is, switch the IDT when the int3 comes in, so
that the subsequent nmi will be handled on the debug stack. As you pointed out,
these nesting and thus the IDT switching would be rare in
practice. (I know you don't want to touch any code outside of nmi :))

Thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/