Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp2610578ybn; Thu, 26 Sep 2019 14:46:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqw49tNjUts+BlBdxiKyAJlxFhc8h1CQBM4EZ2oLytk1/mXNNTApetkhYtxFCbdnOPVSTeHL X-Received: by 2002:a50:9e08:: with SMTP id z8mr1084538ede.305.1569534369565; Thu, 26 Sep 2019 14:46:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569534369; cv=none; d=google.com; s=arc-20160816; b=Exi8Z9ZapuZ/OHLdhIEQ1MErq+WeqKejCYY+Z9Z2L1TJSHp8Ef0/GxkRfzyYiMP1TQ NHdL8v9yfIcgs5PGj4YPRvp8gF2ED3Rnal75fPju50zbKUrkBD8gV6l18UTM+FJXnqwn 07Q18ptZ9QerUIbKWlS3UuYkUzq/tORq/d128pgz3BXs3QQvmU0649jCIMXopDoG/YLE uK+vjaoBe0dGle6pxtoZwoEneO/Hl95csJ39grXWbpKjY+hH94Nhyy3rqJT6raoVtRUX /3icR1GpE6uGqjNKfRlb1K1y07/9xQPWIwgujpcDhtnhSSDvDkvEtagvtd3pHg+Q8F0K NZUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=VgpSKymEXFQZBHIwxggNM0T+DcAbSwcSVJy6Xt4nmRg=; b=AMTwX+Y/SBsn6DmNUTDqBssSgEFn18K0wkElvNl4w02jKscZm+kZkRdUCMlFeU3s0d 6XWu3U8A5d7g2mncINiYnRcMuGjf/A9CRW/POArXba07juIBrXQLrqhb9R1Uqbttu1a7 jAGf+C64ydRLCNelx7jjvTGNCWkeioWiGDNJCKIrylGtx3TReiNSlAWaMHl3DNji4oUf 1N9pmjmB/GgirNBUsjN+gHkvwFihw/taQDltU8ieUIlY2caJWsTyJsBb10M9+30e4MHq Wy8Z8yDBZ0LWXb8fRhV+m88sTsFOU6PHScF4mDgWqMoXD8Wy5il56DfROyOiQqV9Mh8V cy4A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h17si368849edb.89.2019.09.26.14.45.45; Thu, 26 Sep 2019 14:46:09 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726166AbfIZVnE (ORCPT + 99 others); Thu, 26 Sep 2019 17:43:04 -0400 Received: from mga07.intel.com ([134.134.136.100]:8270 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725943AbfIZVnE (ORCPT ); Thu, 26 Sep 2019 17:43:04 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 14:43:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,553,1559545200"; d="scan'208";a="192958527" Received: from sjchrist-coffee.jf.intel.com ([10.54.74.41]) by orsmga003.jf.intel.com with ESMTP; 26 Sep 2019 14:43:03 -0700 From: Sean Christopherson To: Paolo Bonzini , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Reto Buerki Subject: [PATCH 0/2] KVM: nVMX: Bug fix for consuming stale vmcs02.GUEST_CR3 Date: Thu, 26 Sep 2019 14:43:00 -0700 Message-Id: <20190926214302.21990-1-sean.j.christopherson@intel.com> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Reto Buerki reported a failure in a nested VMM when running with HLT interception disabled in L1. When putting L2 into HLT, KVM never actually enters L2 and instead cancels the nested run and pretends that VM-Enter to L2 completed and then exited on HLT (which KVM intercepted). Because KVM never actually runs L2, KVM skips the pending MMU update for L2 and so leaves a stale value in vmcs02.GUEST_CR3. If the next wake event for L2 triggers a nested VM-Exit, KVM will refresh vmcs12->guest_cr3 from vmcs02.GUEST_CR3 and consume the stale value. Fix the issue by unconditionally writing vmcs02.GUEST_CR3 during nested VM-Enter instead of deferring the update to vmx_set_cr3(), and skip the update of GUEST_CR3 in vmx_set_cr3() when running L2. I.e. make the nested code fully responsible for vmcs02.GUEST_CR3. I really wanted to go with a different fix of handling this as a one-off case in the HLT flow (in nested_vmx_run()), and then following that up with a cleanup of VMX's CR3 handling, e.g. to do proper dirty tracking instead of having the nested code do manual VMREADs and VMWRITEs. I even went so far as to hide vcpu->arch.cr3 (put CR3 in vcpu->arch.regs), but things went south when I started working through the dirty tracking logic. Because EPT can be enabled *without* unrestricted guest, enabling EPT doesn't always mean GUEST_CR3 really is the guest CR3 (unlike SVM's NPT). And because the unrestricted guest handling of GUEST_CR3 is dependent on whether the guest has paging enabled, VMX can't even do a clean handoff based on unrestricted guest. In a nutshell, dynamically handling the transitions of GUEST_CR3 ownership in VMX is a nightmare, so fixing this purely within the context of nested VMX turned out to be the cleanest fix. Sean Christopherson (2): KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter KVM: VMX: Skip GUEST_CR3 VMREAD+VMWRITE if the VMCS is up-to-date arch/x86/kvm/vmx/nested.c | 8 ++++++++ arch/x86/kvm/vmx/vmx.c | 15 ++++++++++----- 2 files changed, 18 insertions(+), 5 deletions(-) -- 2.22.0