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 11:12:08 +0200 Message-ID: <49EAEAE8.7010600@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> <49EAE76E.5050302@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig066E1D97A20F988E7CF839FE" Cc: Gleb Natapov , kvm@vger.kernel.org, joerg.roedel@amd.com, sheng@linux.intel.com, Dmitry Baryshkov To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:44217 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752711AbZDSJMR (ORCPT ); Sun, 19 Apr 2009 05:12:17 -0400 In-Reply-To: <49EAE76E.5050302@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig066E1D97A20F988E7CF839FE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >> First, this must return 1 (or set an exit reason, but there is no reas= on >> to escape to user space here). And second, I think a corner case is no= t >> handled the same way as on real iron: If there is already the next NMI= >> waiting, we will inject it before iret, not after its execution as it >> should be. >> =20 >=20 > Yes, good catch. >=20 >> No easy solution for this yet. Maybe emulating iret, but there is no >> implementation, specifically for protected mode.=20 >=20 > That will be a disaster, IRET is horribly complicated. Yeah, I know... >=20 >> Maybe setting a >> breakpoint. Or maybe enforcing a single step exception.=20 >=20 > Single step looks good, except that it may conflict with a guest > debugging itself (guest debugging an NMI handler?!). But that should be solvable without too much effort. BTW, guest single-stepping in and out of interrupt handlers is not properly working anyway. We only set TF in current eflags but do not bother about the CPU state that will get loaded next. Given some rainy days (or a paying customer) I think I'll look into this once again. Same goes for suppressing IRQ injection while single-stepping just as QEMU does, which may even come earlier as someone already asked for it. >=20 >> Nothing trivial >> in this list. On the other hand, this may only be a slight imprecision= >> of the virtualization. Need to think about it. >> =20 >=20 > It may cause a stack overflow if we have a huge stream of NMIs (if an > NMI triggers an NMI in the handler). Of course that's a totally > unrealistic scenario. >=20 Good point. But as it is a corner case, I think we can fly without a complete solution first, fixing it in a second step. Jan --------------enig066E1D97A20F988E7CF839FE 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 iEYEARECAAYFAknq6u4ACgkQniDOoMHTA+miBQCePHZkS95QMwhGlyNsKJ9Ssax5 AKcAnR5K3P9VZQAjtXgmmG6Wo6hRLbN1 =wpbN -----END PGP SIGNATURE----- --------------enig066E1D97A20F988E7CF839FE--