Jan Kiszka wrote:
First, this must return 1 (or set an exit reason, but there is no reason
to escape to user space here). And second, I think a corner case is not
handled the same way as on real iron: If there is already the next NMI
waiting, we will inject it before iret, not after its execution as it
should be.
Yes, good catch.
No easy solution for this yet. Maybe emulating iret, but there is no
implementation, specifically for protected mode.
That will be a disaster, IRET is horribly complicated.
Maybe setting a
breakpoint. Or maybe enforcing a single step exception.
Single step looks good, except that it may conflict with a guest
debugging itself (guest debugging an NMI handler?!).
Nothing trivial
in this list. On the other hand, this may only be a slight imprecision
of the virtualization. Need to think about it.
It may cause a stack overflow if we have a huge stream of NMIs (if an
NMI triggers an NMI in the handler). Of course that's a totally
unrealistic scenario.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
