On 2011-02-03 16:07, 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. >> > > 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? Joerg and I discussed this a few times, I think last on the KVM forum. It's really tricky and we found no option without limitations. Single-stepping, e.g., already pollutes the guest state (if an exception is taken without prior vmexit). I don't recall all alternatives, but a vmexit-saving one was (IIRC) to fall back to an interrupt window without IRET interception, likely augmented with some break-out timer like we do for oldish, vnmi-lacking Intels. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
