From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: VMX: NMI injection without virtual NMI support Date: Sat, 13 Sep 2008 08:27:10 +0200 Message-ID: <48CB5D3E.1000505@web.de> References: <48C93512.4050805@siemens.com> <200809121429.51455.sheng.yang@intel.com> <48CA298A.8080404@siemens.com> <48CB4C2A.5030804@qumranet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig672037664FDAF52BEC8E081E" Cc: "Yang, Sheng" , kvm-devel To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:33879 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752292AbYIMG1M (ORCPT ); Sat, 13 Sep 2008 02:27:12 -0400 In-Reply-To: <48CB4C2A.5030804@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig672037664FDAF52BEC8E081E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >> Well, I thought in this direction already as well. But I wasn't sure i= f, >> while the guest is in NMI context, hard IRQs will also be blocked and >> won't cause guest exists anymore. Can you comment on this? >> >> However, even if that is no issue, I do not really like this workaroun= d. >> Specifically the need to fiddle with the guest's IDT and, of course, >> that we may delays host NMIs. >> >> I'm now playing with this idea, basically a "light" version of yours: >> After we injected an NMI, consider the guest being in NMI context unti= l >> the next IRQ window opens. That may cause lost NMIs if the guest block= s >> IRQ delivery infinitely, but I would say this is rather untypical and >> still much better than the current situation (no NMIs at all!). And it= >> is easier to implement. Comments? >> >> >> =20 >=20 >=20 > In some cases misbehaving NMIs are worse than no NMIs. For example, a > software watchdog may use NMIs to monitor a system. But if the guest > spins with interrupts disabled, the irq window will never open, and NMI= s > will never be delivered, so the watchdog will deliver a false negative.= >=20 I fail to see the regression. Currently that watchdog would _always_ deliver false positives and pull the trigger immediately (in fact, this is precisely the situation we face @work with some special board emulation where we have to provide an NMI-based watchdog). Moreover, only the second and succeeding NMIs under the same interrupts-disabled window need to get lost: Along with injecting the first NMI we could request the IRQ window unconditionally, using it to reset the virtual NMI-blocked state. Jan --------------enig672037664FDAF52BEC8E081E 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 iEYEARECAAYFAkjLXT4ACgkQniDOoMHTA+ldpgCfX7RKtvFtqreqEE5YKYYzzSK+ lpcAnRByIh5XEgnvCJn2iQ4uXXmIIx1f =YlAL -----END PGP SIGNATURE----- --------------enig672037664FDAF52BEC8E081E--