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: Sun, 19 Apr 2009 15:40:24 +0200 Message-ID: <49EB29C8.6020707@web.de> References: <1239616545-25199-1-git-send-email-gleb@redhat.com> <1239616545-25199-14-git-send-email-gleb@redhat.com> <49E8DEC1.4030802@web.de> <20090419131735.GG10126@redhat.com> <49EB26BA.9020200@web.de> <20090419133222.GK10126@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0319E699BDB90063636BBDB5" Cc: avi@redhat.com, kvm@vger.kernel.org, joerg.roedel@amd.com, sheng@linux.intel.com, Dmitry Baryshkov To: Gleb Natapov Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:60462 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758081AbZDSNke (ORCPT ); Sun, 19 Apr 2009 09:40:34 -0400 In-Reply-To: <20090419133222.GK10126@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0319E699BDB90063636BBDB5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Sun, Apr 19, 2009 at 03:27:22PM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Fri, Apr 17, 2009 at 09:55:45PM +0200, Jan Kiszka wrote: >>>> Gleb Natapov wrote: >>>>> Signed-off-by: Gleb Natapov >>>>> --- >>>>> arch/x86/include/asm/kvm_host.h | 1 + >>>>> arch/x86/kvm/svm.c | 49 +++++++++++++++++++++++++++= ++++++++++- >>>>> 2 files changed, 48 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm= /kvm_host.h >>>>> index 8b6f6e9..057a612 100644 >>>>> --- a/arch/x86/include/asm/kvm_host.h >>>>> +++ b/arch/x86/include/asm/kvm_host.h >>>>> @@ -766,6 +766,7 @@ enum { >>>>> #define HF_GIF_MASK (1 << 0) >>>>> #define HF_HIF_MASK (1 << 1) >>>>> #define HF_VINTR_MASK (1 << 2) >>>>> +#define HF_NMI_MASK (1 << 3) >>>>> =20 >>>>> /* >>>>> * Hardware virtualization extension instructions may fault if a >>>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >>>>> index c605477..cd60fd7 100644 >>>>> --- a/arch/x86/kvm/svm.c >>>>> +++ b/arch/x86/kvm/svm.c >>>>> @@ -1834,6 +1834,13 @@ static int cpuid_interception(struct vcpu_sv= m *svm, struct kvm_run *kvm_run) >>>>> return 1; >>>>> } >>>>> =20 >>>>> +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; >>>>> +} >>>> First, this must return 1 (or set an exit reason, but there is no re= ason >>>> to escape to user space here). And second, I think a corner case is = not >>>> handled the same way as on real iron: If there is already the next N= MI >>>> waiting, we will inject it before iret, not after its execution as i= t >>>> should be. >>>> >>>> No easy solution for this yet. Maybe emulating iret, but there is no= >>>> implementation, specifically for protected mode. Maybe setting a >>>> breakpoint. Or maybe enforcing a single step exception. Nothing triv= ial >>>> in this list. On the other hand, this may only be a slight imprecisi= on >>>> of the virtualization. Need to think about it. >>>> >>> What about this: >>> Instead of clearing HF_NMI_MASK in iret_interception() we can set >>> another flag (HF_IRET) and on guest entry clear HF_NMI_MASK (and >>> HF_IRET) if HF_IRET is set, but do that after checking for NMI >>> injection. The pending NMI will be injected on the next entry. >>> Also not how real HW works, but may be better then current situation.= >> It's OK as a first step towards correct NMI emulation. Additionally, y= ou >> could enable the IRQ window interception in case the is an NMI pending= =2E >> The resulting behavior should then much like the VNMI mask emulation f= or >> vmx. >> > Yeah, but the question is if IRQ windows is already opened will exit > happens before or after IRET. >=20 Hey, this is band-aid, it won't heal all cases. ;) Jan --------------enig0319E699BDB90063636BBDB5 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 iEYEARECAAYFAknrKdAACgkQniDOoMHTA+mzpgCdFuTSQqxkc9T9dwU+1KVFrAqL dEAAnA34qVkjZQsFYBg2OmwTd2RqvPJG =tc/8 -----END PGP SIGNATURE----- --------------enig0319E699BDB90063636BBDB5--