From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: RE: [PATCH 07/31] nVMX: Introduce vmcs02: VMCS used to run L2 Date: Tue, 24 May 2011 08:54:10 +0800 Message-ID: <625BA99ED14B2D499DC4E29D8138F1505C9BEF06CC@shsmsx502.ccr.corp.intel.com> References: <1305575004-nyh@il.ibm.com> <201105161947.p4GJlUJb001735@rice.haifa.ibm.com> <625BA99ED14B2D499DC4E29D8138F1505C9BEEFE29@shsmsx502.ccr.corp.intel.com> <625BA99ED14B2D499DC4E29D8138F1505C9BEEFE8F@shsmsx502.ccr.corp.intel.com> <20110520203211.GA5519@fermat.math.technion.ac.il> <625BA99ED14B2D499DC4E29D8138F1505C9BEEFFD8@shsmsx502.ccr.corp.intel.com> <20110522072231.GA186@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: "kvm@vger.kernel.org" , "gleb@redhat.com" , "avi@redhat.com" To: Nadav Har'El Return-path: Received: from mga09.intel.com ([134.134.136.24]:24445 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753100Ab1EXAy1 convert rfc822-to-8bit (ORCPT ); Mon, 23 May 2011 20:54:27 -0400 In-Reply-To: <20110522072231.GA186@fermat.math.technion.ac.il> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: > From: Nadav Har'El [mailto:nyh@math.technion.ac.il] > Sent: Sunday, May 22, 2011 3:23 PM > > Hi, > > On Sun, May 22, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX: > Introduce vmcs02: VMCS used to run L2": > > Here the vmcs02 being overridden may have been run on another processor > before > > but is not vmclear-ed yet. When you resume this vmcs02 with new content on > a > > separate processor, the risk of corruption exists. > > I still believe that my current code is correct (in this area). I'll try to > explain it here and would be grateful if you could point to me the error (if > there is one) in my logic: > > Nested_vmx_run() is our function which is switches from running L1 to L2 > (patch 18). > > This function starts by calling nested_get_current_vmcs02(), which gets us > *some* vmcs to use for vmcs02. This may be a fresh new VMCS, or a > "recycled" > VMCS, some VMCS we've previously used to run some, potentially different L2 > guest on some, potentially different, CPU. > nested_get_current_vmcs02() returns a "saved_vmcs" structure, which > not only contains a VMCS, but also remembers on which (if any) cpu it is > currently loaded (and whether it was VMLAUNCHed once on that cpu). > > The next thing that Nested_vmx_run() now does is to set up in the vcpu object > the vmcs, cpu and launched fields according to what was returned above. > > Now it calls vmx_vcpu_load(). This standard KVM function checks if we're now > running on a different CPU from the vcpu->cpu, and if it a different one, is > uses vcpu_clear() to VMCLEAR the vmcs on the CPU where it was last loaded > (using an IPI). Only after it vmclears the VMCS on the old CPU, it can finally > load the VMCS on the new CPU. > > Only now Nested_vmx_run() can call prepare_vmcs02, which starts > VMWRITEing > to this VMCS, and finally returns. > yes, you're correct. Previously I just looked around 07/31 and raised above concern. Along with nested_vmx_run you explained above, this part is clear to me now. :-) > P.S. Seeing that you're from Intel, maybe you can help me with a pointer: > I found what appears to be a small error in the SDM - who can I report it to? > Let me ask for you. Thanks Kevin