From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 8/9] VMX: work around lacking VNMI support Date: Sun, 21 Sep 2008 20:08:41 +0200 Message-ID: <48D68DA9.4090606@web.de> References: <48D392F2.300@siemens.com> <48D39555.4020106@siemens.com> <20080921143144.GB27089@minantech.com> <48D67CFC.5030700@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55328C0D4133F961792F3A30" Cc: kvm-devel , "Yang, Sheng" , Avi Kivity To: Gleb Natapov Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:32944 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750996AbYIUSIo (ORCPT ); Sun, 21 Sep 2008 14:08:44 -0400 In-Reply-To: <48D67CFC.5030700@web.de> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55328C0D4133F961792F3A30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Gleb Natapov wrote: >> Hi Jan, >> >> On Fri, Sep 19, 2008 at 02:04:37PM +0200, Jan Kiszka wrote: >>> static void vmx_inject_irq(struct kvm_vcpu *vcpu, int irq) >>> { >>> struct vcpu_vmx *vmx =3D to_vmx(vcpu); >>> @@ -2356,6 +2384,29 @@ static void vmx_inject_nmi(struct kvm_vc >>> { >>> struct vcpu_vmx *vmx =3D to_vmx(vcpu); >>> =20 >>> + if (!cpu_has_virtual_nmis()) { >>> + int desc_size =3D is_long_mode(vcpu) ? 16 : 8; >>> + struct descriptor_table dt; >>> + gpa_t gpa; >>> + u64 desc; >>> + >>> + /* >>> + * Deny delivery if the NMI will not be handled by an >>> + * interrupt gate (workaround depends on IRQ masking). >>> + */ >>> + vmx_get_idt(vcpu, &dt); >>> + if (!vcpu->arch.rmode.active && dt.limit >>> + >=3D desc_size * (NMI_VECTOR + 1) - 1) { >>> + gpa =3D vcpu->arch.mmu.gva_to_gpa(vcpu, >>> + dt.base + desc_size * NMI_VECTOR); >>> + if (kvm_read_guest(vcpu->kvm, gpa, &desc, 8) =3D=3D 0 >>> + && ((desc >> 40) & 0x7) !=3D 0x6) >>> + return; >>> + } >> Windows2003 sets NMI entry in IDT as a task gate (0x5) during hibernat= ion and this check >> prevents it from shutting down itself. It hangs in "It is save to turn= >> your computer now" screen. >=20 > Grmbl, what a weird guest... >=20 > Is this a regression of this patch because NMIs were considered broken > by Windows on that host CPU so far? >=20 >> If I replace this part by: >> if(vmx->soft_vnmi_blocked) >> return; >> It shut itself down properly. >=20 > OK, but that almost always evaluates to false here. >=20 > I guess (hope) Windows will switch to an NMI task which has IRQs > disabled (!(TSS.EFLAGS & IF)), so this may become another check for > those weird task users. Waiting on the next IRQ window for NMI injectio= n > should work equally well with tasks, given they disable IRQs properly. I thought about it again, fortunately before implementing this horribly complex additional check: These safety belts make no real sense. Even if we double-check that the guest is starting to handle NMIs with IRQs disabled, it may still fiddle with its IRQ mask before the originally NMI-enabling iret, confusing our soft_vmi_blocked maintenance. So, instead of adding more paranoid checks, let's drop them altogether, relying on reasonably designed guests that have IRQs disabled as long as NMIs are handled. If they come with such weirdness, all we may cause is virtual NMI nesting in fairly rare cases for such unusual guests (if they exist at all). Jan --------------enig55328C0D4133F961792F3A30 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 iEYEARECAAYFAkjWjakACgkQniDOoMHTA+n0GwCdH+z6WHxmsm7iz8N0rcyE+WvB jXEAn1GSQHsT88xj+tNzxPjFkmrqrK5p =NSpF -----END PGP SIGNATURE----- --------------enig55328C0D4133F961792F3A30--