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 21:37:17 +0100 Message-ID: <513505FD.8000509@web.de> References: <20130304141515.GQ23616@redhat.com> <5134AEEB.9020600@siemens.com> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QQSEQDBXTPRWJEHBLPFO" Cc: Marcelo Tosatti , kvm , Nadav Har'El , "Nakajima, Jun" To: Gleb Natapov Return-path: Received: from mout.web.de ([212.227.17.12]:52037 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932242Ab3CDUh0 (ORCPT ); Mon, 4 Mar 2013 15:37:26 -0500 In-Reply-To: <20130304202413.GI14220@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QQSEQDBXTPRWJEHBLPFO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-03-04 21:24, Gleb Natapov wrote: >>> That doesn't make sense to me. I do not even sure what you are saying= >>> since you do not specify what shadow is matched. From the code I see >>> that on CR0 exit to L0 from L2 we check if L2 tries to change CR0 bit= s >>> 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 yo= u >>> 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 shado= w >> (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 the= > one example of how we can get here if you think that it is not clear en= ough. > The TS part was useful to me. Hmm, if the comment was helpful, why did you have to ask me what was wrong? :) 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." For me, ignoring TS made things clearer and simpler. HTH, Jan ------enig2QQSEQDBXTPRWJEHBLPFO 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/ iEYEARECAAYFAlE1Bf4ACgkQitSsb3rl5xRgjQCg4S5d3wMDFBMipiMIpo579IwV lkQAn3FI7p06xKEiqb4pZ+U7+/Dm/Cco =ZCSd -----END PGP SIGNATURE----- ------enig2QQSEQDBXTPRWJEHBLPFO--