From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 3/3] KVM: nVMX: check for null vmcs12 when L1 does invept Date: Sun, 23 Mar 2014 20:16:50 +0100 Message-ID: <532F3322.7060404@web.de> References: <1395286089-5406-1-git-send-email-bsd@redhat.com> <1395286089-5406-4-git-send-email-bsd@redhat.com> <532AB624.4020400@siemens.com> <532D764E.20607@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jGvABk0tLKVqIVgGRo7Po2XjlsDUov3uv" Cc: kvm@vger.kernel.org, Paolo Bonzini , Gleb Natapov To: Bandan Das Return-path: Received: from mout.web.de ([212.227.17.12]:52768 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbaCWTQ6 (ORCPT ); Sun, 23 Mar 2014 15:16:58 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jGvABk0tLKVqIVgGRo7Po2XjlsDUov3uv Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2014-03-22 17:43, Bandan Das wrote: > Jan Kiszka writes: >=20 >> On 2014-03-20 21:58, Bandan Das wrote: >>> Jan Kiszka writes: >>> >>>> On 2014-03-20 04:28, Bandan Das wrote: >>>>> Some L1 hypervisors such as Xen seem to be calling invept after >>>>> vmclear or before vmptrld on L2. In this case, proceed with >>>>> falling through and syncing roots as a case where >>>>> context wide invalidation can't be supported >>>> >>>> Can we also base this behaviour on a statement in the SDM? But on fi= rst >>>> glance, I do not find anything like this over there. >>> >>> The SDM has nothing of this sort explicitly mentioned but 28.3.3.1=20 >>> "Operations that invalidate Cached Mappings" does mention that >>> the instruction may invalidate mappings associated with other >>> EP4TAs (even in single context). >> >> Yes, "may". So we are implementing undefined behavior in order to plea= se >> a broken hypervisor that relies on it? Then please state this in the >> patch and probably also inform Xen about their issue. >=20 > Why undefined behavior ? We don't do anything specific for=20 > the single context invalidation case ianyway .e If the eptp matches wha= t=20 > vmcs12 has, single context invalidation does fall though to the global = > invalidation case already. All this change does is add the "L1 calls=20 > invept after vmclear and before vmptrld" to the list of cases to fall = > though to global invalidation since nvmx doesn't have any knowledge of = > the current eptp for this case. OK, I think I misunderstood what the guest expects and how we currently achieve this: we do not track the mapping between guest and host eptp, thus cannot properly emulate its behaviour. We therefore need to flush everything. >=20 > Or do you think we should rethink this approach ? Well, I wonder if we should expose single-context invept support at all. I'm also wondering if we are returning proper flags on if ((operand.eptp & eptp_mask) !=3D (nested_ept_get_cr3(vcpu) & eptp_mask)) break; Neither nested_vmx_succeed nor nested_vmx_fail* is called if this condition evaluates to true. Jan --jGvABk0tLKVqIVgGRo7Po2XjlsDUov3uv 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMvMyUACgkQitSsb3rl5xQylACfeOapEPk3JYS8OVt40HImq17X 1YoAoMV3fFJs9Jd8dMezmAwz23wxmrDr =ZJpd -----END PGP SIGNATURE----- --jGvABk0tLKVqIVgGRo7Po2XjlsDUov3uv--