From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: nVMX: Fully support of nested VMX preemption timer Date: Sun, 25 Aug 2013 10:13:43 +0200 Message-ID: <5219BCB7.3070109@web.de> References: <1377369850-18583-1-git-send-email-root@Blade1-01.Blade1-01> <5219A7BA.8050602@web.de> <5219B590.7040304@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="plXRA20G2XPssFwvegAjPhqJJ4dwti1TF" Cc: Arthur Chunqi Li , Gleb Natapov , kvm , kvm-owner@vger.kernel.org, Paolo Bonzini To: Abel Gordon Return-path: Received: from mout.web.de ([212.227.15.14]:55095 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756100Ab3HYINq (ORCPT ); Sun, 25 Aug 2013 04:13:46 -0400 Received: from mchn199C.mchp.siemens.de ([95.157.58.223]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0MK2FR-1VEKOz2TuH-001Q1Y for ; Sun, 25 Aug 2013 10:13:44 +0200 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --plXRA20G2XPssFwvegAjPhqJJ4dwti1TF Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable On 2013-08-25 10:04, Abel Gordon wrote: >=20 >=20 > kvm-owner@vger.kernel.org wrote on 25/08/2013 10:55:24 AM: >=20 >> From: Arthur Chunqi Li >> To: Abel Gordon/Haifa/IBM@IBMIL, >> Cc: Jan Kiszka , Gleb Natapov , >> kvm , kvm-owner@vger.kernel.org, Paolo Bonzini >> >> Date: 25/08/2013 10:55 AM >> Subject: Re: [PATCH] KVM: nVMX: Fully support of nested VMX preemption= > timer >> Sent by: kvm-owner@vger.kernel.org >> >> On Sun, Aug 25, 2013 at 3:50 PM, Abel Gordon wrote:= >>> >>> >>> kvm-owner@vger.kernel.org wrote on 25/08/2013 10:43:12 AM: >>> >>>> From: Jan Kiszka >>>> To: Abel Gordon/Haifa/IBM@IBMIL, >>>> Cc: gleb@redhat.com, kvm@vger.kernel.org, kvm-owner@vger.kernel.org,= >>>> pbonzini@redhat.com, "=1B$BM{=3DU4q=1B(B " >>>> Date: 25/08/2013 10:43 AM >>>> Subject: Re: [PATCH] KVM: nVMX: Fully support of nested VMX preempti= on >>> timer >>>> Sent by: kvm-owner@vger.kernel.org >>>> >>>> On 2013-08-25 09:37, Abel Gordon wrote: >>>>> >>>>> >>>>>> From: Jan Kiszka >>>>>> To: "=1B$BM{=3DU4q=1B(B " , >>>>>> Cc: kvm@vger.kernel.org, gleb@redhat.com, pbonzini@redhat.com >>>>>> Date: 25/08/2013 09:44 AM >>>>>> Subject: Re: [PATCH] KVM: nVMX: Fully support of nested VMX > preemption >>>>> timer >>>>>> Sent by: kvm-owner@vger.kernel.org >>>>>> >>>>>> On 2013-08-24 20:44, root wrote: >>>>>>> This patch contains the following two changes: >>>>>>> 1. Fix the bug in nested preemption timer support. If vmexit L2->= > L0 >>>>>>> with some reasons not emulated by L1, preemption timer value > should >>>>>>> be save in such exits. >>>>>>> 2. Add support of "Save VMX-preemption timer value" VM-Exit > controls >>>>>>> to nVMX. >>>>>>> >>>>>>> With this patch, nested VMX preemption timer features are fully >>>>>>> supported. >>>>>>> >>>>>>> Signed-off-by: Arthur Chunqi Li >>>>>>> --- >>>>> >>>>>>> >>>>>>> @@ -7578,9 +7579,14 @@ static void prepare_vmcs02(struct kvm_vcpu= >>>>>> *vcpu, struct vmcs12 *vmcs12) >>>>>>> (vmcs_config.pin_based_exec_ctrl | >>>>>>> vmcs12->pin_based_vm_exec_control)); >>>>>>> >>>>>>> - if (vmcs12->pin_based_vm_exec_control & >>>>> PIN_BASED_VMX_PREEMPTION_TIMER) >>>>>>> - vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, >>>>>>> - vmcs12->vmx_preemption_timer_value); >>>>>>> + if (vmcs12->pin_based_vm_exec_control & >>>>>> PIN_BASED_VMX_PREEMPTION_TIMER) { >>>>>>> + if (vmcs12->vm_exit_controls & >>>>> VM_EXIT_SAVE_VMX_PREEMPTION_TIMER) >>>>>>> + vmcs12->vmx_preemption_timer_value =3D >>>>>>> + vmcs_read32(VMX_PREEMPTION_TIMER_VALUE); >>>>>>> + else >>>>>>> + vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, >>>>>>> + vmcs12->vmx_preemption_timer_value); >>>>>>> + } >>>>>> >>>>>> This is not correct. We still need to set the vmcs to >>>>>> vmx_preemption_timer_value. The difference is that, on exit from > L2, >>>>>> vmx_preemption_timer_value has to be updated according to the save= d >>>>>> hardware state. The corresponding code is missing in your patch so= >>> far. >>>>> >>>>> I think something else maybe be missing here: assuming L0 handles > exits >>>>> for L2 without involving L1 (e.g. external interrupts or ept >>> violations), >>>>> then, we may spend some cycles in L0 handling these exits. Note L1 > is >>> not >>>>> aware of these exits and from L1 perspective L2 was running on the > CPU. >>>>> That means that we may need to reduce these cycles spent at >>>>> L0 from the preemtion timer or emulate a preemption timer exit to >>>>> force a transition to L1 instead of resuming L2. >>>> >>>> That's precisely what the logic I described should achieve: reload t= he >>>> value we saved on L2 exit on reentry. >>> >>> But don't you think we should also reduce the cycles spent at L0 from= > the >>> preemption timer ? I mean, if we spent X cycles at L0 handling a L2 > exit >>> which was not forwarded to L1, then, before we resume L2, >>> the preemption timer should be: (previous_value_on_exit - X). >>> If (previous_value_on_exit - X) < 0, then we should force ("emulate")= a >>> preemption timer exit between L2 and L1. >> Sorry, I previously misunderstand your comments. But why should we >> need to exclude cycles in L0 from L2 preemption value? These cycles >> are not spent by L2 and it should not be on L2. >=20 > L1 asked the "hardware" (emulated by L0) to run L2 and force an exit > after "Y" cycles. Now, in practice, we may spend "X" cycles at L0 handl= ing > exits without switching to L1. That means that from L1 perspective L2 > was running all these X cycles. L1 should assume that the instructions = per > cycle > the CPU executed decreased but the cycles were spent. That's why I beli= eve > you should take in account these X cycles. >=20 Now I get it. There is likely some truth in this as the reference clock for the preemption timer, the TSC, isn't stopped for L1/L2 while running in L0. And the SDM demands the countdown to be proportional to that clock= =2E Jan --plXRA20G2XPssFwvegAjPhqJJ4dwti1TF 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/ iEYEARECAAYFAlIZvLcACgkQitSsb3rl5xQihwCbBe4m+QO2ze2ZzIaPUZBTqrYj ejoAoOA9HLQI0THP08hMxq9+ZVPmdrgs =J49c -----END PGP SIGNATURE----- --plXRA20G2XPssFwvegAjPhqJJ4dwti1TF--