From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 13/15] Add NMI injection support to SVM. Date: Sat, 18 Apr 2009 11:08:17 +0200 Message-ID: <49E99881.4080605@web.de> References: <1239616545-25199-1-git-send-email-gleb@redhat.com> <1239616545-25199-14-git-send-email-gleb@redhat.com> <20090417191346.GA9743@doriath.ww600.siemens.net> <49E8DE41.8030706@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF36E3B3E1445CC75798BE966" Cc: kvm-owner@vger.kernel.org, avi@redhat.com, kvm@vger.kernel.org, joerg.roedel@amd.com, sheng@linux.intel.com, Gleb Natapov To: Dmitry Eremin-Solenikov Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:44739 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751359AbZDRJIT (ORCPT ); Sat, 18 Apr 2009 05:08:19 -0400 In-Reply-To: <49E8DE41.8030706@web.de> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF36E3B3E1445CC75798BE966 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Dmitry Eremin-Solenikov wrote: >> On Mon, Apr 13, 2009 at 12:55:43PM +0300, kvm-owner@vger.kernel.org wr= ote: >>> Signed-off-by: Gleb Natapov >> The attached patch if applied on the top of the serie fixes the NMI is= sue on >> SVM. I did not refactor it on the top of this patch though, sorry. >> >> >> From 26d7e88c84089abbe871286d54e77ff2922dc33d Mon Sep 17 00:00:00 2001= >> From: Dmitry Eremin-Solenikov >> Date: Fri, 17 Apr 2009 22:53:50 +0400 >> Subject: [PATCH] KVM: correct NMI injection logic wrt NMI window track= ing >> >> inject_pending_irq() calls inject_irq() which disables nmi_pending fla= g >> if the nmi was injected. Thus for tracking we should use nmi_injected >> flag. This al fin fixes NMI injection on SVM. >> >> Signed-off-by: Dmitry Eremin-Solenikov >> --- >> arch/x86/kvm/x86.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index e4cc717..eeed350 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -3160,7 +3160,7 @@ static void inject_pending_irq(struct kvm_vcpu *= vcpu, struct kvm_run *kvm_run) >> inject_irq(vcpu); >> =20 >> /* enable NMI/IRQ window open exits if needed */ >> - if (vcpu->arch.nmi_pending) >> + if (vcpu->arch.nmi_injected) >> kvm_x86_ops->enable_nmi_window(vcpu); >> else if (kvm_cpu_has_interrupt(vcpu) || req_int_win) >> kvm_x86_ops->enable_irq_window(vcpu); >=20 > Hmm, good to know that it works better now, but I'm afraid this papers > over an issue in svm (and will break other cases). The logic here is: W= e > injected something (IRQ or NMI), and if there is more pending, _then_ > enable the corresponding window. The check you changed should actually > only fire if we (re-)injected an IRQ for this round, and now there is > also an NMI pending. >=20 > My feeling is that the real issue is in svm which probably fails to ope= n > the NMI window on NMI injection. In contrast to latest Intel CPUs, we > have to do this unconditionally on AMD (no virtual NMI mask). And as > this is so, svm has to take care that this is done on injection, not > here via the generic code. What about setting INTERCEPT_IRET > additionally in svm_inject_nmi? >=20 Yep, this also allows to inject >1 NMI here: diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index af61744..79b9d8b 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -1831,7 +1831,7 @@ static int iret_interception(struct vcpu_svm *svm, = struct kvm_run *kvm_run) { svm->vmcb->control.intercept &=3D ~(1UL << INTERCEPT_IRET); svm->vcpu.arch.hflags &=3D ~HF_NMI_MASK; - return 0; + return 1; } =20 static int invlpg_interception(struct vcpu_svm *svm, struct kvm_run *kvm= _run) @@ -2232,6 +2232,7 @@ static void svm_inject_nmi(struct kvm_vcpu *vcpu) struct vcpu_svm *svm =3D to_svm(vcpu); =20 svm->vmcb->control.event_inj =3D SVM_EVTINJ_VALID | SVM_EVTINJ_TYPE_NMI= ; + svm->vmcb->control.intercept |=3D (1UL << INTERCEPT_IRET); svm->vcpu.arch.hflags |=3D HF_NMI_MASK; } =20 Jan --------------enigF36E3B3E1445CC75798BE966 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknpmIEACgkQniDOoMHTA+n6LwCffEUBCyk2gwLDS6HUR3BHswcO GrYAn1vyjpOJG/AdE0R59rnv2cPIycrh =czGA -----END PGP SIGNATURE----- --------------enigF36E3B3E1445CC75798BE966--