From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 2/2] KVM: SVM: check for progress after IRET interception Date: Thu, 03 Feb 2011 16:21:07 +0100 Message-ID: <4D4AC7E3.7070408@siemens.com> References: <1296745369-12066-1-git-send-email-avi@redhat.com> <1296745369-12066-3-git-send-email-avi@redhat.com> <4D4AC4B5.7060009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , Joerg Roedel To: Avi Kivity Return-path: Received: from thoth.sbs.de ([192.35.17.2]:21163 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755435Ab1BCPVY (ORCPT ); Thu, 3 Feb 2011 10:21:24 -0500 In-Reply-To: <4D4AC4B5.7060009@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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