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:55:05 +0100 Message-ID: <4D4ACFD9.9000203@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> <4D4AC7E3.7070408@siemens.com> <4D4ACA0D.4090707@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 goliath.siemens.de ([192.35.17.28]:18752 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752336Ab1BCPzX (ORCPT ); Thu, 3 Feb 2011 10:55:23 -0500 In-Reply-To: <4D4ACA0D.4090707@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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