On 02/03/2011 05:02 PM, Avi Kivity wrote:
When we enable an NMI window, we ask for an IRET intercept, since the IRET re-enables NMIs. However, the IRET intercept happens before the instruction executes, while the NMI window architecturally opens afterwards. To compensate for this mismatch, we only open the NMI window in the following exit, assuming that the IRET has by then executed; however, this assumption is not always correct; we may exit due to a host interrupt or page fault, without having executed the instruction. Fix by checking for forward progress by recording and comparing the IRET's rip. This is somewhat of a hack, since an unchaging rip does not mean that no forward progress has been made, but is the simplest fix for now.
So what would be a better fix? We could unconditionally single step on iret_interception() which would fix the problem at the cost of making NMIs less efficient (three exits instead of two). We could emulate the IRET (doubling kvm's code and likely slower, and certainly buggier, than the first option). Alternatively, can anyone think of a reliable way to make sure forward progress has been made?
-- error compiling committee.c: too many arguments to function -- 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
