On Thu, Feb 03, 2011 at 05:07:33PM +0200, Avi Kivity wrote: > 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. > > Looks good. > 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? Is there other negative impact of the RIP hack than NMI being delayed? -- 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
