Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3828510ybb; Mon, 23 Mar 2020 08:25:32 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtagylGemzqYEcEiF4CwtalCvR2wljO7IlFfghgYKHGKlkmP5//yd+8lqvyaT3GgIuwTbF6 X-Received: by 2002:aca:4e57:: with SMTP id c84mr16680714oib.148.1584977131984; Mon, 23 Mar 2020 08:25:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584977131; cv=none; d=google.com; s=arc-20160816; b=00eb1+40apsKk5wvqMvn/6wTt+GK3yzGaMUJI/kJpy8X6ESbJN/KClce/Y/j7qoaQL N1XgROwRnem5ArUXOTIQY+q2f4/KjsQvuPWoGopUVbIOp3PFdqDk1kD00XHeAnWKWQwa YAl6klEVRmLxEO+PocmyUOPypR9188zJ5IXs9FkQ6CXrjQHwxCpTJGYSbFKUWQb2hrgB A/ZqAWH8ainuSrWxUgCJjL5d2zBvWMAT3S/AH0I/AUVBonpUjY+Bt7BEhyPPFXDHd1Ii w7e/U10WfZHdECOoPhxWl3PSmv9yVcS/1ltpPHoaDyDJvcuwYOHJR29k7d1TcmibhAwD GwrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=FY0p3cqwN918CaX62qQRQ+vCrkce6hk743BEWFF5l9Q=; b=TtgzFdLhdrTO7peSseNy+GM4QAwMlV1v2JeXLOv6a163Zi8SHv/VwDJ2xcDXDmmHwK 8F1GNbdbxT7AjPWNYXUSA5alcKt6RDqV2hf4UjJLhVBmTNKJF2+g2eZMoXPYyh7oPmWy xn799y/DDjMKdPx9ggV8mze8dDGxZ9LyZc6PJITidY/ZheK8sQ2rIlUEesiVqCbIE1J+ iTsQN10PjOOXFF0PVpnSZZm/S2fa/tOpidt7Ai0bQcaHibflBYeWhb8CN9lmh7PMABUH K5DAvYpioXtk7gpjWRA/N655BWoiXHFmEzWMCU3odCD3nov5g3v0TZVYx3cm+C3H70ps KQlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="YclV/LyO"; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e27si8135735oiy.72.2020.03.23.08.25.16; Mon, 23 Mar 2020 08:25:31 -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=@redhat.com header.s=mimecast20190719 header.b="YclV/LyO"; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727186AbgCWPYO (ORCPT + 99 others); Mon, 23 Mar 2020 11:24:14 -0400 Received: from us-smtp-delivery-74.mimecast.com ([63.128.21.74]:53131 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727151AbgCWPYN (ORCPT ); Mon, 23 Mar 2020 11:24:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584977052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FY0p3cqwN918CaX62qQRQ+vCrkce6hk743BEWFF5l9Q=; b=YclV/LyOZH+tZn0dDfOn4mKZ4+9jZtqb1QMGmTT3z7fIF5l7c7W0TSPOovIkRjsa7JHksN jTv1yYyCQd/CkFdJANQ63Lj5+1wQHHeYZT/Pt22JkCqIGc9Pl3JbyFX3cclQmKjWN5reK8 9sh5BQ6nHYhe/HOH5b16/2sTPzwk7aU= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-170-e5paFfcuPS672nWx1NRb9g-1; Mon, 23 Mar 2020 11:24:11 -0400 X-MC-Unique: e5paFfcuPS672nWx1NRb9g-1 Received: by mail-wr1-f69.google.com with SMTP id m15so3101714wrb.0 for ; Mon, 23 Mar 2020 08:24:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=FY0p3cqwN918CaX62qQRQ+vCrkce6hk743BEWFF5l9Q=; b=IuNLNhGHRZmmZmcTzS1wCesToXE09jV6F9D/OBgJe0vT6+rrWLQoLK516rXTlWLYGR 0le9FivpSkEUHSsOJr5vJ78A9kHVPOF2W5NX8NAODXhoS3DCkdVMmUAGRw/5lhigCGB1 CmiiZqUpQq1PnePLNk+N15WOM9taahdXIcC19tys+wxj7/FnSmWszclc9nH3flAT7eBc xkvxLVIse9oh5JBPZGkoI8rgBvJSK96nI9nir5dAP7gcw5j1oV21To3TSlHLQghDAH8G HMGAG/TYktkspMTBtL+pn6ydxBCkZfQNIwGzo3jW2KDCVaMFL5zTYdXfaH5drzcUIeVO BjGw== X-Gm-Message-State: ANhLgQ3sqypq+38zBl0+9fI6tw70PNpsjFpuukRhCdiZOQkxU6xmPWfM U9xuXIJKbIkTbTdvqhlVUeRiWYMkIxRbKWowxERrjqaLgQkUrCG1KhNw0IOixA9RqvZZMXVumBz UmairzhANKk5DgZ5HFvFUVcWo X-Received: by 2002:a05:600c:2943:: with SMTP id n3mr6891040wmd.119.1584977048259; Mon, 23 Mar 2020 08:24:08 -0700 (PDT) X-Received: by 2002:a05:600c:2943:: with SMTP id n3mr6891012wmd.119.1584977048031; Mon, 23 Mar 2020 08:24:08 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id f10sm24052628wrw.96.2020.03.23.08.24.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2020 08:24:07 -0700 (PDT) From: Vitaly Kuznetsov To: Sean Christopherson , Paolo Bonzini Cc: 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 03/37] KVM: nVMX: Invalidate all EPTP contexts when emulating INVEPT for L1 In-Reply-To: <20200320212833.3507-4-sean.j.christopherson@intel.com> References: <20200320212833.3507-1-sean.j.christopherson@intel.com> <20200320212833.3507-4-sean.j.christopherson@intel.com> Date: Mon, 23 Mar 2020 16:24:05 +0100 Message-ID: <87y2rr857u.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sean Christopherson writes: > Free all L2 (guest_mmu) roots when emulating INVEPT for L1. Outstanding > changes to the EPT tables managed by L1 need to be recognized, and > relying on KVM to always flush L2's EPTP context on nested VM-Enter is > dangerous. > > Similar to handle_invpcid(), rely on kvm_mmu_free_roots() to do a remote > TLB flush if necessary, e.g. if L1 has never entered L2 then there is > nothing to be done. > > Nuking all L2 roots is overkill for the single-context variant, but it's > the safe and easy bet. A more precise zap mechanism will be added in > the future. Add a TODO to call out that KVM only needs to invalidate > affected contexts. > > Fixes: b119019847fbc ("kvm: nVMX: Remove unnecessary sync_roots from handle_invept") > Reported-by: Jim Mattson > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/vmx/nested.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index f3774cef4fd4..9624cea4ed9f 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -5160,12 +5160,12 @@ static int handle_invept(struct kvm_vcpu *vcpu) > if (!nested_vmx_check_eptp(vcpu, operand.eptp)) > return nested_vmx_failValid(vcpu, > VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID); > + > + /* TODO: sync only the target EPTP context. */ > fallthrough; > case VMX_EPT_EXTENT_GLOBAL: > - /* > - * TODO: Sync the necessary shadow EPT roots here, rather than > - * at the next emulated VM-entry. > - */ > + kvm_mmu_free_roots(vcpu, &vcpu->arch.guest_mmu, > + KVM_MMU_ROOTS_ALL); > break; An ignorant reader may wonder "and how do we know that L1 actaully uses EPT" as he may find out that guest_mmu is not being used otherwise. The answer to the question will likely be "if L1 doesn't use EPT for some of its guests than there's nothing we should do here as we will be resetting root_mmu when switching to/from them". Hope the ignorant reviewer typing this is not very wrong :-) > default: > BUG_ON(1); Reviewed-by: Vitaly Kuznetsov -- Vitaly