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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
