From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: nVMX: Fix setting of CR0 and CR4 in guest mode Date: Mon, 04 Mar 2013 22:09:44 +0100 Message-ID: <51350D98.4030702@web.de> References: <20130304175632.GD14220@redhat.com> <5134E308.3000202@siemens.com> <20130304183956.GF14220@redhat.com> <5134F4C8.9010807@web.de> <20130304193331.GG14220@redhat.com> <5134F802.2020200@web.de> <20130304200033.GH14220@redhat.com> <51350029.6080908@web.de> <20130304202413.GI14220@redhat.com> <513505FD.8000509@web.de> <20130304210035.GJ14220@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QQSFPGPIGICKEHGURBRP" Cc: Marcelo Tosatti , kvm , Nadav Har'El , "Nakajima, Jun" To: Gleb Natapov Return-path: Received: from mout.web.de ([212.227.17.12]:50657 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932210Ab3CDVJ4 (ORCPT ); Mon, 4 Mar 2013 16:09:56 -0500 In-Reply-To: <20130304210035.GJ14220@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QQSFPGPIGICKEHGURBRP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-03-04 22:00, Gleb Natapov wrote: > On Mon, Mar 04, 2013 at 09:37:17PM +0100, Jan Kiszka wrote: >> On 2013-03-04 21:24, Gleb Natapov wrote: >>>>> That doesn't make sense to me. I do not even sure what you are sayi= ng >>>>> since you do not specify what shadow is matched. From the code I se= e >>>>> that on CR0 exit to L0 from L2 we check if L2 tries to change CR0 b= its >>>>> that L1 claims to belong to it and do #vmexit to L1 if it is: >>>>> >>>>> if (vmcs12->cr0_guest_host_mask & (val ^ vmcs12->cr0_read_shadow= )) >>>>> return 1; >>>>> >>>>> We never reach handle_set_cr0() in that case. >>>>> >>>>> Can you provide an example with actual values for L2/L1/L0 of what = you >>>>> are trying to say? >>>> >>>> I already provided a concrete one: L1 clears PE/PG from its >>>> guest_host_mask (assuming we support unrestricted guest mode for L1)= , L2 >>>> switches from real to protected mode, thus sets PE=3D1 while the sha= dow >>>> (set by L0) holds 0 =3D> we end up in handle_set_cr0. >>>> >>> So how is this "inverse of what the comment suggest"? I do not >>> understand your grudge against the comment. Just clarify that TS is t= he >>> one example of how we can get here if you think that it is not clear = enough. >>> The TS part was useful to me. >> >> Hmm, if the comment was helpful, why did you have to ask me what was >> wrong? :) >> > Comment helped me understand what's the case that should be handled > here. I didn't asked you what was wrong, Nadav did, but that's because > I haven't wrapped my mind around this code yet. I will ask it later :) >=20 >> If you insist on clarification, let's try it again: >> >> "We get here when L2 changed cr0 in a way that did not change >> any of L1's shadowed bits (see nested_vmx_exit_handled_cr), >> but did change L0 shadowed bits. KVM only hands over TS to L1, >> and that only if the FPU is enabled. So we will be called for >> every change that L1 allows L2 to perform natively." >=20 > I find this much more confusing that original comment. Actually > re-reading the original one I do not think it's about KVM as L2 either.= > What bout: >=20 > We get here when L2 changed cr0 in a way that did not change > any of L1's shadowed bits (see nested_vmx_exit_handled_cr), > but did change L0 shadowed bits. This may happen with > the TS bit: L0 may want to leave TS on (for lazy fpu loading) > while pretending to allow the guest to change it. Which guest? >=20 > So in your case it may happen to PE, but TS is only an example anyway. Not thinking about TS avoids the additional complication it brings because L0 may change its mind about guest ownership. Other bits are unconditionally L0-owned. Jan ------enig2QQSFPGPIGICKEHGURBRP 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/ iEYEARECAAYFAlE1DZgACgkQitSsb3rl5xSjjwCfeaDTMDi2pe6+5E7YZjKsC4GZ qJMAnRY+jLw1PFQK1vSqM4IxTyXsG8Yz =zcWM -----END PGP SIGNATURE----- ------enig2QQSFPGPIGICKEHGURBRP--