From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 18/24] Exiting from L2 to L1 Date: Mon, 13 Sep 2010 13:53:56 +0800 Message-ID: <201009131353.56814.sheng@linux.intel.com> References: <1276431753-nyh@il.ibm.com> <20100912170503.GA7828@fermat.math.technion.ac.il> <4C8D0C19.4050003@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Nadav Har'El" , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mga01.intel.com ([192.55.52.88]:8940 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859Ab0IMFwt convert rfc822-to-8bit (ORCPT ); Mon, 13 Sep 2010 01:52:49 -0400 In-Reply-To: <4C8D0C19.4050003@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Monday 13 September 2010 01:21:29 Avi Kivity wrote: > On 09/12/2010 07:05 PM, Nadav Har'El wrote: > >> I don't think so. We write this field as part of guest entry (tha= t is, > >> after the decision re which vmcs to use, yes?), so guest entry wil= l > >> always follow writing this field. Since guest entry clears the fi= eld, > >> reading it after an exit will necessarily return 0. > >=20 > > Well, you obviously know the KVM code much better than I do, but fr= om > > what I saw, I thought (maybe I misunderstood) that in normal > > (non-nested) KVM, this field only gets written on injection, not on > > every entry, so the code relies on the fact that the processor turn= s off > > the "valid" bit during exit, to avoid the same event being injected= when > > the same field value is used for another entry. >=20 > Correct. >=20 > > I can only find code which resets this field in vmx_vcpu_reset(), > > but that doesn't get called on every entry, right? Or am I missing > > something? >=20 > prepare_vmcs12() is called in response for a 2->1 vmexit which is fir= st > trapped by 0, yes? Because it's called immediately after a vmexit, > VM_ENTRY_INTR_INFO_FIELD is guaranteed to have been cleared by the > processor. >=20 > There are two cases where VM_ENTRY_INTR_INFO_FIELD can potentially no= t > be cleared by hardware: >=20 > 1. if we call prepare_vmcs12() between injection and entry. This can= not > happen AFAICT. > 2. if the vmexit was really a failed 1->2 vmentry, and if the process= or > doesn't clear VM_ENTRY_INTR_INFO_FIELD in response to vm entry failur= es > (need to check scripture) >=20 > If neither of these are valid, the code can be removed. If only the > second, we might make it conditional. >=20 > >> What can happen is that the contents of the field is transferred t= o the > >> IDT_VECTORING_INFO field or VM_EXIT_INTR_INFO field. > >>=20 > >> (question: on a failed vmentry, is this field cleared?) > >=20 > > I don't know the answer :-) >=20 > Sheng? According to SDM 23.7 "VM-ENTRY FAILURES DURING OR AFTER LOADING GUEST STATE": Although this process resembles that of a VM exit, many steps taken dur= ing a VM=20 exit do not occur for these VM-entry failures: =E2=80=A2 Most VM-exit information fields are not updated (see step 1 a= bove). =E2=80=A2 The valid bit in the VM-entry interruption-information field = is *not* cleared. =E2=80=A2 The guest-state area is not modified. =E2=80=A2 No MSRs are saved into the VM-exit MSR-store area. So VM entry failure would result in _keep_ valid bit of VM_ENTRY_INTR_I= NFO_FIELD. -- regards Yang, Sheng