Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3865094ybb; Mon, 23 Mar 2020 09:06:00 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvrKZWcaVMNs0v3kFarMKCddAcjclyEEqz7OG/Vnq7MQqO6nCOhsXpP0BZmbUqD8lkrRKMZ X-Received: by 2002:a9d:1b31:: with SMTP id l46mr7688454otl.95.1584979560693; Mon, 23 Mar 2020 09:06:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584979560; cv=none; d=google.com; s=arc-20160816; b=RY9lPvaYTWDuP/5gf5+6kkzugkk/WqXmCyayFiFEaMCFMVNAYZVlxuVm9PSdoxnDyx whKv1KMUhgFPVqdGMnoFkeS+iLmS6pzqE7LlJ1OXqm/SWyvAjq14VnzQJ2uni4QYkgJZ 8rVVZgDmAOBOJbcSTSbjXfnzmQFzJQ9F0suxXcQdCD4ZDYnompt+KWbtdm2hQN7Hw7Xb xwfzx3b1F4ipHFMeyFflG4oc+Vvfr2ufu+Je2PspWY6wmBWpYqfUQmlWBrq78rxhPSir 33O6fo6o8MgtUftHeJfFY2TbKYaENQpuUDkogt+ulj36PzMlpN+ZERzDSb8t1YY7jz32 WfiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=sfm1ZPO7smjJYxTciU4wByOGGzd5sh/Xye22s0nuYdc=; b=PE6Go1ohejXLUnpv0OcsO229Y6i4CyKvHVMroTJAXl35D6Q29YLxRjOAM5vxlt65kf sq0TGcA4/4l9U/LUhOSNVBSD716qjT3YdJVH4gK66/pR/tT3hW7yMWzEyoEdB5UWkIb5 u3RtC7yVwgwBLonhuEE+UR1xu9ix/J41pC5Bw5/9U0NPRoNuMSXz22i2dt/rqWWCUKDe 5s5nG8GFDu+Ij/EPwU/cy/fB53JTfZBR5QPiWKacRVwYcwXK6kMME+8u18aB9+FgdWf1 Qg6Bhsy8PEsQTAYSgU4XBTUIty4+cfJojXsB48gUPC4M7FObBDDhnH3oKQaZS46zTzlp Ynhg== 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 x63si7320626oia.101.2020.03.23.09.05.20; Mon, 23 Mar 2020 09:06:00 -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 S1727445AbgCWQEe (ORCPT + 99 others); Mon, 23 Mar 2020 12:04:34 -0400 Received: from mga05.intel.com ([192.55.52.43]:53089 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727194AbgCWQEd (ORCPT ); Mon, 23 Mar 2020 12:04:33 -0400 IronPort-SDR: COJtxdyDi78DFmABqF/UJ0spSQE+qPnpYFmOQHmOTvtajj3f4TihAL4BHi75Ju3me/2SLrr1T7 l7Vn8l+FYeYg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2020 09:04:33 -0700 IronPort-SDR: 8160iWQQn2QB9EBkZ/5az9FGQyLtlP8gpZ2wwPk4GGyG8uGZK6pSLjteJMiLAc6G0Mv9/pLSSz btIvTAF8I0UQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,296,1580803200"; d="scan'208";a="269922152" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by fmsmga004.fm.intel.com with ESMTP; 23 Mar 2020 09:04:32 -0700 Date: Mon, 23 Mar 2020 09:04:32 -0700 From: Sean Christopherson To: Vitaly Kuznetsov Cc: Paolo Bonzini , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Gardon , Junaid Shahid , Liran Alon , Boris Ostrovsky , John Haxby , Miaohe Lin , Tom Lendacky Subject: Re: [PATCH v3 04/37] KVM: nVMX: Invalidate all roots when emulating INVVPID without EPT Message-ID: <20200323160432.GJ28711@linux.intel.com> References: <20200320212833.3507-1-sean.j.christopherson@intel.com> <20200320212833.3507-5-sean.j.christopherson@intel.com> <87v9mv84qu.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9mv84qu.fsf@vitty.brq.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 23, 2020 at 04:34:17PM +0100, Vitaly Kuznetsov wrote: > Sean Christopherson writes: > > > From: Junaid Shahid > > > > Free all roots when emulating INVVPID for L1 and EPT is disabled, as > > outstanding changes to the page tables managed by L1 need to be > > recognized. Because L1 and L2 share an MMU when EPT is disabled, and > > because VPID is not tracked by the MMU role, all roots in the current > > MMU (root_mmu) need to be freed, otherwise a future nested VM-Enter or > > VM-Exit could do a fast CR3 switch (without a flush/sync) and consume > > stale SPTEs. > > > > Fixes: 5c614b3583e7b ("KVM: nVMX: nested VPID emulation") > > Signed-off-by: Junaid Shahid > > [sean: ported to upstream KVM, reworded the comment and changelog] > > Signed-off-by: Sean Christopherson > > --- > > arch/x86/kvm/vmx/nested.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > > index 9624cea4ed9f..bc74fbbf33c6 100644 > > --- a/arch/x86/kvm/vmx/nested.c > > +++ b/arch/x86/kvm/vmx/nested.c > > @@ -5250,6 +5250,20 @@ static int handle_invvpid(struct kvm_vcpu *vcpu) > > return kvm_skip_emulated_instruction(vcpu); > > } > > > > + /* > > + * Sync the shadow page tables if EPT is disabled, L1 is invalidating > > + * linear mappings for L2 (tagged with L2's VPID). Free all roots as > > + * VPIDs are not tracked in the MMU role. > > + * > > + * Note, this operates on root_mmu, not guest_mmu, as L1 and L2 share > > + * an MMU when EPT is disabled. > > + * > > + * TODO: sync only the affected SPTEs for INVDIVIDUAL_ADDR. > > + */ > > + if (!enable_ept) > > + kvm_mmu_free_roots(vcpu, &vcpu->arch.root_mmu, > > + KVM_MMU_ROOTS_ALL); > > + > > This is related to my remark on the previous patch; the comment above > makes me think I'm missing something obvious, enlighten me please) > > My understanding is that L1 and L2 will share arch.root_mmu not only > when EPT is globally disabled, we seem to switch between > root_mmu/guest_mmu only when nested_cpu_has_ept(vmcs12) but different L2 > guests may be different on this. Do we need to handle this somehow? guest_mmu is used iff nested EPT is enabled, which requires enable_ept=1. enable_ept is global and cannot be changed without reloading kvm_intel. This most definitely over-invalidates, e.g. it blasts away L1's page tables. But, fixing that requires tracking VPID in mmu_role and/or adding support for using guest_mmu when L1 isn't using TDP, i.e. nested EPT is disabled. Assuming the vast majority of nested deployments enable EPT in L0, the cost of both options likely outweighs the benefits. > > return nested_vmx_succeed(vcpu); > > } > > -- > Vitaly >