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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13051C433FE for ; Wed, 23 Mar 2022 18:49:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344070AbiCWSvL (ORCPT ); Wed, 23 Mar 2022 14:51:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344032AbiCWSvB (ORCPT ); Wed, 23 Mar 2022 14:51:01 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66D7C60CC8 for ; Wed, 23 Mar 2022 11:49:31 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id g19-20020a17090a579300b001b9d80f3714so1528204pji.7 for ; Wed, 23 Mar 2022 11:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=i3y/R2G/yOzk3wi7p2qOKXA2BvyWMGeSAE7HqxAnaPU=; b=eZP/RLC9xeAaOFNwwbxYUIxPtQMvTN3IXnMmR4pGyi2YtpEhddJBpbpmaTPlJD1MYD 1LivnC4WvLcy+TtAP1TFFzuD35h42ZXmVOtHd4cn7vMNKfDVtNNrKdVPLAfNJnajfCsb c8DX7jLm1/Da4Cv8rR+1R2oBGizMEEbDZoaWHGXlr5I9XdE4M1aMRAc6VjZxJ+wyU6KC OBZoBMaArnYbwAU3rogO0VToAPFYgdJY//UDGCMX6YljpHNPHkHAwHMoPOld2MbEBSKF d8WjcmsMnQYBKH6f2XJ1VP19vPxMpbypqayzj/MUSwLpUkChdDY1hmBHhP2ZRb3KhWQf GC1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=i3y/R2G/yOzk3wi7p2qOKXA2BvyWMGeSAE7HqxAnaPU=; b=al2jpc6UGjq88tPvgHB6PayGjZbdSOr9+goTby8Lqi9+T0zUKgdzMERu2vkLvxR7B4 Rexot11V4HvJx3ZHH9eOmVa8Tm1hflLvV90lcq2DXNmdEwKohNeN6JFAR7j65Zf4wxyt 5SolqR3iANZfGAudBN5QTuNF5JQmzWL/4pW9RhLEEYbxl/c+S8u8jg5+7tKxyHaMjIb5 nuIEZ2FB+M+IvF8lsxeBmHXo6JtyoYCt0Qt+yOQL33TBrDNk72SKHwb4rmgpUQ/rT3rG 7d1lzR1gZSsM+oBK1idoupNknuy5o6S9ERgCm8gn03Jj3nujGadMIU+sus/oz1fSisn9 7WxQ== X-Gm-Message-State: AOAM531TBOnHSFG+mXgJxTU0WKBwSelZkBIzS4PNvutG2Vk+QlmBw4ux QHpw0z70iJtI3GRJfi9EZrGnwoeuwiBJ X-Google-Smtp-Source: ABdhPJwy9+hoP4haE+2RiusYHIP0dKJx4cZVl9ra6s7X/D91BaloL9b86cNA0SFB2RLUzX7nIuAmslbBtlfI X-Received: from mizhang-super.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:1071]) (user=mizhang job=sendgmr) by 2002:a17:90a:1d04:b0:1bc:98ca:5e6f with SMTP id c4-20020a17090a1d0400b001bc98ca5e6fmr13721397pjd.32.1648061370937; Wed, 23 Mar 2022 11:49:30 -0700 (PDT) Reply-To: Mingwei Zhang Date: Wed, 23 Mar 2022 18:49:14 +0000 In-Reply-To: <20220323184915.1335049-1-mizhang@google.com> Message-Id: <20220323184915.1335049-5-mizhang@google.com> Mime-Version: 1.0 References: <20220323184915.1335049-1-mizhang@google.com> X-Mailer: git-send-email 2.35.1.1021.g381101b075-goog Subject: [PATCH v2 3/4] KVM: x86/mmu: explicitly check nx_hugepage in disallowed_hugepage_adjust() From: Mingwei Zhang To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Gardon , Mingwei Zhang , David Matlack , Jing Zhang , Peter Xu Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add extra check to specify the case of nx hugepage and allow KVM to reconstruct large mapping after dirty logging is disabled. Existing code works only for nx hugepage but the condition is too general in that does not consider other usage case (such as dirty logging). Note that when dirty logging is disabled, KVM calls kvm_mmu_zap_collapsible_sptes() which only zaps leaf SPTEs. Moreover, existing code assumes that a present PMD or PUD indicates that there exist 'smaller SPTEs' under the paging structure. This assumption may no be true if KVM zaps only leafs in MMU. Missing the check causes KVM incorrectly regards the faulting page as a NX huge page and refuse to map it at desired level. And this leads to back performance issue in shadow mmu and potentially in TDP mmu as well. Fixes: b8e8c8303ff2 ("kvm: mmu: ITLB_MULTIHIT mitigation") Cc: stable@vger.kernel.org Reviewed-by: Ben Gardon Signed-off-by: Mingwei Zhang --- arch/x86/kvm/mmu/mmu.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 5628d0ba637e..d9b2001d8217 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -2919,6 +2919,16 @@ void disallowed_hugepage_adjust(struct kvm_page_fault *fault, u64 spte, int cur_ cur_level == fault->goal_level && is_shadow_present_pte(spte) && !is_large_pte(spte)) { + struct kvm_mmu_page *sp; + u64 page_mask; + /* + * When nx hugepage flag is not set, there is no reason to go + * down to another level. This helps KVM re-generate large + * mappings after dirty logging disabled. + */ + sp = to_shadow_page(spte & PT64_BASE_ADDR_MASK); + if (!sp->lpage_disallowed) + return; /* * A small SPTE exists for this pfn, but FNAME(fetch) * and __direct_map would like to create a large PTE @@ -2926,8 +2936,8 @@ void disallowed_hugepage_adjust(struct kvm_page_fault *fault, u64 spte, int cur_ * patching back for them into pfn the next 9 bits of * the address. */ - u64 page_mask = KVM_PAGES_PER_HPAGE(cur_level) - - KVM_PAGES_PER_HPAGE(cur_level - 1); + page_mask = KVM_PAGES_PER_HPAGE(cur_level) - + KVM_PAGES_PER_HPAGE(cur_level - 1); fault->pfn |= fault->gfn & page_mask; fault->goal_level--; } -- 2.35.1.1021.g381101b075-goog