On 02/03/2011 05:21 PM, Jan Kiszka wrote:
> > 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).
We could enable all intercepts when single stepping. if we get a single-step #DB, we clear nmi blocking and are happy. If we get another exception, or a non-single-step #DB, we re-enable the IRET intercept, clear single-step, re-inject the exception, and let the guest continue.
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.
What's an interrupt window without IRET interception? -- 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
