On 02/08/2011 03:49 PM, Marcelo Tosatti wrote:
> >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?
Worst case scenario is that we always exit before the IRET for some reason, so the NMI is delayed forever. It's incredibly unlikely though, I can't think of a sensible way to construct such a case (an insensible way: an IRET that returns to itself - on 64-bit, IRET pops RSP, so it's easy to arrange such a loop).
-- 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
