From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB676C31E49 for ; Thu, 13 Jun 2019 16:16:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BDB8120665 for ; Thu, 13 Jun 2019 16:16:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="aDuX9qqO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391596AbfFMQQm (ORCPT ); Thu, 13 Jun 2019 12:16:42 -0400 Received: from mail-yb1-f202.google.com ([209.85.219.202]:51141 "EHLO mail-yb1-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731613AbfFMQQl (ORCPT ); Thu, 13 Jun 2019 12:16:41 -0400 Received: by mail-yb1-f202.google.com with SMTP id v83so2783348ybv.17 for ; Thu, 13 Jun 2019 09:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=OuMoHtUYB/A86Igsd2Mm9vXsE800Nj7kR2sJJAc9Dbo=; b=aDuX9qqOZjqcr0AlhJo2kyypwZIqpYn2rb3eahHvIdvXh+2pO2ay2/B0LzlcqWKev5 Eanlx3KbVCydE/uF1iPZdvZ457wehyXNqKUBKbo7Q8sJAFH5MI3HmAPnfQlRc2bYfntH 96IAvwSuDgzmWpvtdCRjQn3oWyoe5j3xhGTRh+535dGJVIkz4QhURuoTmjR4sxOM4gBN cUEkpS1sChUvCzmVFNd3hlzcCstgli5HcNRFmzxZ7ZE9uMB0Xc8vE91StRcFdKUEUFDJ E2QAgl0OiCJ5iPcd/vJJZniOZNJ91sHaQDlU9gXOQ2FTwCec9G1yK5LXMsU+GbW9pUpP ojSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=OuMoHtUYB/A86Igsd2Mm9vXsE800Nj7kR2sJJAc9Dbo=; b=E/hpszk3vYFIFty4IIyy5LPMF1x1dgzz3aclSckAT3OQvlqauRgAeRsHiAfFejRU5s k0Anric7JFUF1WHAdt/hNVJaYimlbPM7VtX9RtXfS7VTDOmdt8X3crycmZ5N6omXFIxg vMMlJcfJtFk0tbzwR8FPN7YtWhYcBQhQNJyUNEQv3d3QUUWzL6rX/sE2RGFy4coe62jA z8ZIhex3DZzUIaTey0ixThRqvg4tH5XhLo2kMg7hBbc/pk5cxERHqn3sl3IV+PsaQMYj 0T+CXizyEW90QVICSUTC7hFsfYCFu//gfmbTDzCSnCHzJ8xSTisJa+7poW/vy+wzoRQM nmkA== X-Gm-Message-State: APjAAAU2cGt/5IdsfNteW1egSqT2HWkIwbzoU+cup3fY6gksX9U2KO0y qHA9/lxHgzcc5tpeS57Xfa2WvC5MypX12/21IrQxFvOdetw42/sN1eji6A+KGgU/6Xg0lxto3pa 9qu78NJbft8N8/WNkBL1R8MyI2V2Azcu3zgQ9k6bl10UFcsci4DeSdXOZyozo+8s= X-Google-Smtp-Source: APXvYqylxuoKMV14ZdRos6vtaDG1Hi/hNuInyUQPfIXpV2awbxsj8pSt9m/ruXeGk2KkUPk75Qvqwd6qhbrMTw== X-Received: by 2002:a81:51d6:: with SMTP id f205mr20200170ywb.228.1560442600592; Thu, 13 Jun 2019 09:16:40 -0700 (PDT) Date: Thu, 13 Jun 2019 09:16:08 -0700 Message-Id: <20190613161608.120838-1-jmattson@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.22.0.rc2.383.gf4fbbf30c2-goog Subject: [PATCH] kvm: nVMX: Remove unnecessary sync_roots from handle_invept From: Jim Mattson To: kvm@vger.kernel.org Cc: Jim Mattson , Junaid Shahid , Xiao Guangrong , "Nadav Har'El" , Jun Nakajima , Xinhao Xu , Yang Zhang , Gleb Natapov , Paolo Bonzini Content-Type: text/plain; charset="UTF-8" Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org When L0 is executing handle_invept(), the TDP MMU is active. Emulating an L1 INVEPT does require synchronizing the appropriate shadow EPT root(s), but a call to kvm_mmu_sync_roots in this context won't do that. Similarly, the hardware TLB and paging-structure-cache entries associated with the appropriate shadow EPT root(s) must be flushed, but requesting a TLB_FLUSH from this context won't do that either. How did this ever work? KVM always does a sync_roots and TLB flush (in the correct context) when transitioning from L1 to L2. That isn't the best choice for nested VM performance, but it effectively papers over the mistakes here. Remove the unnecessary operations and leave a comment to try to do better in the future. Reported-by: Junaid Shahid Fixes: bfd0a56b90005f ("nEPT: Nested INVEPT") Cc: Xiao Guangrong Cc: Nadav Har'El Cc: Jun Nakajima Cc: Xinhao Xu Cc: Yang Zhang Cc: Gleb Natapov Cc: Paolo Bonzini Reviewed-by Peter Shier Reviewed-by: Junaid Shahid Signed-off-by: Jim Mattson --- arch/x86/kvm/vmx/nested.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 1032f068f0b9..35621e73e726 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4670,13 +4670,11 @@ static int handle_invept(struct kvm_vcpu *vcpu) switch (type) { case VMX_EPT_EXTENT_GLOBAL: + case VMX_EPT_EXTENT_CONTEXT: /* - * TODO: track mappings and invalidate - * single context requests appropriately + * TODO: Sync the necessary shadow EPT roots here, rather than + * at the next emulated VM-entry. */ - case VMX_EPT_EXTENT_CONTEXT: - kvm_mmu_sync_roots(vcpu); - kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu); break; default: BUG_ON(1); -- 2.22.0.rc2.383.gf4fbbf30c2-goog