Xen project Mailing List

3) SMM mode executing an iret will re-enable NMIs. There is nothing we
can do to prevent this, and as an SMI can interrupt NMIs and MCEs, no
way to predict if/when it may happen. The best we can do is accept that
it might happen, and try to deal with the after effects.

Did you actually mean IRET, or did you mean RSM? Does it make a difference?

As for 1 possible solution which we cant use:

If it were not for the sysret stupidness[1] of requiring the hypervisor
to move to the guest stack before executing the `sysret` instruction, we
could do away with the stack tables for NMIs and MCEs alltogether, and
the above crazyness would be easy to fix. However, the overhead of
always using iret to return to ring3 is not likely to be acceptable,
meaning that we cannot "fix" the problem by discarding interrupt stacks
and doing everything properly on the main hypervisor stack.

64-bit Intel processors have SYSEXIT, right? It's worth pointing out the following alternatives, even if we never actually use them:

1. Use SYSEXIT on Intel processors and let the bugs (or some subset of them) remain on AMD
2. Use SYSEXIT on Intel processors and IRET on AMD

Given that AMD has cut back their investment in OSS development, and is talking about moving to ARM, it may only be a matter of time before Intel is the only important player in the x86 world.

[1] In an effort to prevent a flamewar with my comment, the situation we
find outself in now is almost certainly the result of unforseen
interactions of individual features, but we are left to pick up the many
pieces in way which cant completely be solved.

The very first time I heard that SYSRET didn't restore the stack pointer, I thought it was an obviously stupid idea that would cause all kinds of crazy bugs. When you're designing operating systems, a little paranoia is a good thing, and I can't help but think that the architects that let this go through made a big mistake here.

-George

Re: [Xen-devel] Woes of NMIs and MCEs, and possibly how to fix