Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp2722995ybn; Thu, 26 Sep 2019 16:45:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqwzekvEsLTmy/WwqP7Mts7fwgvPbcnTXIj2/Lyiq5bmsHp7fzOGMm3EKPjx2H0FA8oZd1Rs X-Received: by 2002:a50:a41c:: with SMTP id u28mr1532126edb.185.1569541558823; Thu, 26 Sep 2019 16:45:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569541558; cv=none; d=google.com; s=arc-20160816; b=vgKVqtwNlXuPK2ZNoi/ILg6AKDzVeZ2FJWvvtP5+uKdIjJ/rMvK2JIUilMtI6CeWaL Ej1YkHw/ax9bwWzFpdA20Md4zdzsWVu3Nb0OMclRvdr93DSMPBaYagVE5JcmpDAr/STg 2D+pHfgAh3nuksUGE7h4aWKBPMBY5aTcHMw9tDbr/ZgUSmyb3LXzEDNA0afRpAknUpPl ggUWRBDdDvsp2rdXTrxa/y0u+ol2/Z+1ZdWVsrZx4N6NDeb+GRPRmNqeI5eE28hua/n0 c3YPWj+pQQY99mC4OEn9LeLNMGPzaJMon823+geWFg4ecdZbkWB5xdioa1Hpkp4qb9j7 K0jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=v0cBEf365i2Hkj00ueJY/8kNVMVGUzDIUvSusdb3iJo=; b=axyvOe0QX+uC58qDPHcP2etrD1Yubo6qHL86fo6utx+x71VE4URk0h7zxGZKZz65GK NsM2L91XUjs1uLnDWEm7+/ziU8QC0qrTissxQ5C4k3Mc/T+OIA5UCVMQ5JKOremu1tIc 1eny8w95EFPBCEm/cuUDUDVBC6rCKOwwFxzdP2rDCXFuEptjTfDA19TTs+frBIH0XoFj xYmL8wQQa8eKnsTheHIbmQve/FSi8bA9c+v3LZUQXwwMPydQOkqoktNhsetIucwQ+N4K 23vpmWUm02OLUEyeR6SkaK5lhtoX9pVDHpn1buBq2td3kIcvjrSxyc+gP1YyJmLrKG59 Va1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iarHionm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n8si1862962ejh.169.2019.09.26.16.45.18; Thu, 26 Sep 2019 16:45:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iarHionm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729010AbfIZXjk (ORCPT + 99 others); Thu, 26 Sep 2019 19:39:40 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:42889 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728932AbfIZXjk (ORCPT ); Thu, 26 Sep 2019 19:39:40 -0400 Received: by mail-io1-f65.google.com with SMTP id n197so11165278iod.9 for ; Thu, 26 Sep 2019 16:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v0cBEf365i2Hkj00ueJY/8kNVMVGUzDIUvSusdb3iJo=; b=iarHionmZ9hxwjfPzym+mw593rsAWn5IDAtGQYDnR0d5TvGKCgO/lHCDVGMyzbW3mm g/K1kzkctO0jKXs9GvJCm55o4g6zyX/YN6/dQH8/scep3dO5DDYqW7orr6sxEJldh/mv w0e3pJQ9raKn55fkuT6Q1W6N+niCNrT1lVipTCRSdmnYXP/coS2UZ2ItssxmJeFSkxaW S/ZlveFepDjGeQ54C/Ogt146Hrah1lxDJpdXcIgUypdqU+h/vkNdUcT6PcNmG0YbmajW KOQ6LnlZAtbNV0RwWUYYUK+NXGFUGjL9kJuCM8yWuqZp/lVdrkYFF//VXHSUU6ywODUL +zsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v0cBEf365i2Hkj00ueJY/8kNVMVGUzDIUvSusdb3iJo=; b=d0ZW6f3IfborAtN28TJBmIcscrAuRXQqb8lbtQevKSVa0tfXOWaKZ0BMr7gbE3067S prHFmnJM8EXxEg15kv+N+V3l2X1JhtVZVVJP7FVSpSeVMk9ygGBnGx7Hr2+IKD2LQEhY zjooErkLmosBE4GeQeNaK93jgKWQqKPvf7op9IiUqMVXs+hucUfWCqIbD2h6B0t0h+7A Si4OFxkY/EKsye6zRc4GySBh9GQVojt5tHCQViSOuRzfuc1oVNO9iKqTLhgR/6KL6uzg Q+FNRrzzxu8qzmqnXmPkTjkbJGqPnTe79QUcUO5NTPSALXr5kJL0WlLbTH3ktkZcmH9K X9XA== X-Gm-Message-State: APjAAAU6FWQCrqlCBjtjqht0r94+2mcNmoaIFEAIoMJbcdrUIELZV+sp BGrntB1ls1NRwnHd8BBm6lWQI1plL35GXA4awyfB2w== X-Received: by 2002:a92:5a10:: with SMTP id o16mr1596339ilb.296.1569541179334; Thu, 26 Sep 2019 16:39:39 -0700 (PDT) MIME-Version: 1.0 References: <20190926214302.21990-1-sean.j.christopherson@intel.com> <20190926214302.21990-2-sean.j.christopherson@intel.com> In-Reply-To: <20190926214302.21990-2-sean.j.christopherson@intel.com> From: Jim Mattson Date: Thu, 26 Sep 2019 16:39:28 -0700 Message-ID: Subject: Re: [PATCH 1/2] KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter To: Sean Christopherson Cc: Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm list , LKML , Reto Buerki Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 26, 2019 at 2:43 PM Sean Christopherson wrote: > > Write the desired L2 CR3 into vmcs02.GUEST_CR3 during nested VM-Enter > isntead of deferring the VMWRITE until vmx_set_cr3(). If the VMWRITE > is deferred, then KVM can consume a stale vmcs02.GUEST_CR3 when it > refreshes vmcs12->guest_cr3 during nested_vmx_vmexit() if the emulated > VM-Exit occurs without actually entering L2, e.g. if the nested run > is squashed because L2 is being put into HLT. > > In an ideal world where EPT *requires* unrestricted guest (and vice > versa), VMX could handle CR3 similar to how it handles RSP and RIP, > e.g. mark CR3 dirty and conditionally load it at vmx_vcpu_run(). But > the unrestricted guest silliness complicates the dirty tracking logic > to the point that explicitly handling vmcs02.GUEST_CR3 during nested > VM-Enter is a simpler overall implementation. > > Cc: stable@vger.kernel.org > Reported-by: Reto Buerki > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/vmx/nested.c | 8 ++++++++ > arch/x86/kvm/vmx/vmx.c | 9 ++++++--- > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index 41abc62c9a8a..971a24134081 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -2418,6 +2418,14 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12, > entry_failure_code)) > return -EINVAL; > > + /* > + * Immediately write vmcs02.GUEST_CR3. It will be propagated to vmcs12 > + * on nested VM-Exit, which can occur without actually running L2, e.g. > + * if L2 is entering HLT state, and thus without hitting vmx_set_cr3(). > + */ > + if (enable_ept) > + vmcs_writel(GUEST_CR3, vmcs12->guest_cr3); > + This part of the change I can definitely confirm, since we have a similar change in our fetid pile of commits that have yet to be upstreamed. Thanks for taking care of this one! > /* Late preparation of GUEST_PDPTRs now that EFER and CRs are set. */ > if (load_guest_pdptrs_vmcs12 && nested_cpu_has_ept(vmcs12) && > is_pae_paging(vcpu)) { > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index d4575ffb3cec..b530950a9c2b 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -2985,6 +2985,7 @@ void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3) > { > struct kvm *kvm = vcpu->kvm; > unsigned long guest_cr3; > + bool skip_cr3 = false; > u64 eptp; > > guest_cr3 = cr3; > @@ -3000,15 +3001,17 @@ void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3) > spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock); > } > > - if (enable_unrestricted_guest || is_paging(vcpu) || > - is_guest_mode(vcpu)) > + if (is_guest_mode(vcpu)) > + skip_cr3 = true; > + else if (enable_unrestricted_guest || is_paging(vcpu)) > guest_cr3 = kvm_read_cr3(vcpu); > else > guest_cr3 = to_kvm_vmx(kvm)->ept_identity_map_addr; > ept_load_pdptrs(vcpu); > } > > - vmcs_writel(GUEST_CR3, guest_cr3); > + if (!skip_cr3) > + vmcs_writel(GUEST_CR3, guest_cr3); Is this part of the change necessary, or is it just an optimization to save a redundant VMWRITE? > } > > int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) > -- > 2.22.0 >