From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: nSVM/nVMX: Implement vmexit on INIT assertion Date: Mon, 25 Feb 2013 10:04:50 +0100 Message-ID: <512B2932.5060909@web.de> References: <512A1EF5.2070709@web.de> <20130225080024.GA411@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2UFMLCGKMPMUMTAOUKDDJ" Cc: Marcelo Tosatti , Gleb Natapov , "Nakajima, Jun" , Joerg Roedel , kvm To: Nadav Har'El Return-path: Received: from mout.web.de ([212.227.17.12]:61468 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932228Ab3BYJFH (ORCPT ); Mon, 25 Feb 2013 04:05:07 -0500 In-Reply-To: <20130225080024.GA411@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UFMLCGKMPMUMTAOUKDDJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-02-25 09:00, Nadav Har'El wrote: > On Sun, Feb 24, 2013, Jan Kiszka wrote about "[PATCH] KVM: nSVM/nVMX: I= mplement vmexit on INIT assertion": >> From: Jan Kiszka >> >> On Intel, raising INIT causing an unconditional vmexit. On AMD, this i= s >> controlled by the interception mask. >=20 > Hi, >=20 > I never tried to closely follow the KVM code paths related this code, > but I do have one question: The VMX spec says: >=20 > "The INIT signal is blocked whenever a logical processor is in VMX r= oot > operation. It is not blocked in VMX non-root operation. Instead, IN= ITs > cause VM exits (see Section 22.3, Other Causes of VM Exits)." >=20 > So when running a non-nested L1 guest, or an L2 guest, the new behavior= > appears correct. However, it looks like if L1 is running in root > mode (i.e., did VMXON once but not running L2 now), the INIT signal > needs to be blocked, not do what it does now. It appears (but I'm not s= ure...) > that right now, it causes the L1 guest to lock up, and is not ignored? = Yeah, forgot about this "detail". Unfortunately, this means we need to track the signal state, processing it on vmentry and, on AMD, when GIF becomes 1. Is the nested-related state already saved on AMD, J=F6rg? If not, adding this one would not make things worse at least. Still, missing user space save/restore already breaks reset, not only migration (dunno if this is better on AMD). Jan ------enig2UFMLCGKMPMUMTAOUKDDJ 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.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlErKTUACgkQitSsb3rl5xQpYwCfXMIPxfbyDVvJv5yIbNHAKmTX Ew8AmwRMiRQXukZzcVjZr6wzUN7PlC/w =nr0M -----END PGP SIGNATURE----- ------enig2UFMLCGKMPMUMTAOUKDDJ--