From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v5] KVM: nVMX: Fully support of nested VMX preemption timer Date: Sun, 29 Sep 2013 18:24:16 +0200 Message-ID: <52485430.6040405@web.de> References: <1379319104-10266-1-git-send-email-yzt356@gmail.com> <52444CF6.1020102@redhat.com> <52446C8D.8030000@web.de> <52447335.9090601@redhat.com> <52449CBD.4010603@redhat.com> <5245279A.4090302@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CwKvjOIm0HkcNcW6m3IDQUBnuDQl65NK3" Cc: Arthur Chunqi Li , kvm@vger.kernel.org, gleb@redhat.com, "Zhang, Yang Z" To: Paolo Bonzini Return-path: Received: from mout.web.de ([212.227.15.14]:61671 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753672Ab3I2QYU (ORCPT ); Sun, 29 Sep 2013 12:24:20 -0400 Received: from mchn199C.mchp.siemens.de ([95.157.58.223]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0M5sDZ-1VkSCm31Sb-00xuUx for ; Sun, 29 Sep 2013 18:24:18 +0200 In-Reply-To: <5245279A.4090302@web.de> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CwKvjOIm0HkcNcW6m3IDQUBnuDQl65NK3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-09-27 08:37, Jan Kiszka wrote: > On 2013-09-26 22:44, Paolo Bonzini wrote: >> Il 26/09/2013 19:47, Paolo Bonzini ha scritto: >>> >>> If I only apply this hunk, which disables the preemption timer while >>> in L1: >>> >>> @@ -8396,6 +8375,8 @@ static void nested_vmx_vmexit(struct kvm_vcpu *= vcpu) >>> >>> load_vmcs12_host_state(vcpu, vmcs12); >>> >>> + vmcs_write32(PIN_BASED_VM_EXEC_CONTROL, vmx_pin_based_exec_ct= rl(vmx)); >>> + >>> /* Update TSC_OFFSET if TSC was changed while L2 ran */ >>> vmcs_write64(TSC_OFFSET, vmx->nested.vmcs01_tsc_offset); >>> >>> then the testcase works for somewhat larger values of the preemption = timer >>> (up to ~1500000 TSC cycles), but then fails. >=20 > Err, does this mean we run L1 with PIN_BASED_VM_EXEC_CONTROL of L2? > Ouch. Should be fixed independently. No, it doesn't mean this. L1 and L2 run on different VMCS, thus should be able to set their PIN_BASED_VM_EXEC_CONTROL independently. I have no clue ATM what that hunk can make a difference for you. Will have a closer look. BTW, aren't many VMCS fields written redundantly in prepare_vmcs02? I mean, those that weren't changed by L1 in the shadow VMCS or require updates for other reasons. There seems to be some room for saving a few cycles. Jan --CwKvjOIm0HkcNcW6m3IDQUBnuDQl65NK3 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/ iEYEARECAAYFAlJIVDEACgkQitSsb3rl5xT6cACfWIKo87gqLgzV/gqNHXLMh7dP nfkAnRVApqmN7WAeIdTfSpx1GKLZNxGe =52W7 -----END PGP SIGNATURE----- --CwKvjOIm0HkcNcW6m3IDQUBnuDQl65NK3--