On 2011-02-03 16:30, Avi Kivity wrote: > 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. Yes, I once explored this direction. It should be feasible (though complex), need to check again why I suspended the effort. > >> 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? I don't the details, but I thought you could get something like an interrupt-window-open interception by (fake-)injecting an IRQ and intercepting on VIRQ acceptance. That will not work if returning to and staying in irq-disabled guest code, therefore the timeout, but it should be most efficient (specifically if the guest uses NMIs for things like perf). 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
