On Fri, Mar 27, 2015 at 11:37 AM, Andy Lutomirski <l...@amacapital.net> wrote:
>
> User does sysenter. We end up in native_irq_enable_sysexit. We do:
>
> swapgs
> sti
>
> <-- NMI here can happen on some (all?) cpus, returns successfully
> *with interrupts unmasked*
I think AMD documented that the sti "interrupt shadow" shadows even
NMI. And for Intel, it definitely does not (but "mov ss" and "pop ss"
masks even NMI for the next instruction - so the interrupt shadow is
different for these cases).
That said, it wasn't 100% clear that the "NMI return to immediate
regular interrupt" can actually happen even on Intel. Iirc, there was
some discussion about when the CPU actually tests the IRQ line after
an 'iret'. It might end up testing the IF only after executing the
instruction it returns to, so it's possible that the sequence
.. interrupts disabled ..
sti
sysexit
can not be interrupted by regular interrupts between the 'sti' and the
'sysexit' even if an NMI were to have happened between the two.
> My preferred fix would be to use sysretl instead of sysexit. As far
> as I know, there are no 64-bit CPUs at all that don't support sysretl.
That 'sti+sysexit" is used for the native 32-bit case too, not just
the compat mode for x86-64. So I don't necessarily disagree with using
sysretl, but..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
