Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp4780191rwe; Tue, 30 Aug 2022 17:21:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR57xtSRETm0506NX3TZVR+mH/hBmFuKg0G4IVrSDL+I35LjoNuFfbxV3FGruOEL7O2eXHQa X-Received: by 2002:a63:4c05:0:b0:41d:12ad:e885 with SMTP id z5-20020a634c05000000b0041d12ade885mr20486103pga.130.1661905263137; Tue, 30 Aug 2022 17:21:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661905263; cv=none; d=google.com; s=arc-20160816; b=LlAlDrDBnZvAjMBqdsZk0XPVLNggLBObLBfPkckj/2wAXq4ZuJkqAthzfqRklKB8Qk IInNgjY/EvpLrsxg97GIclcwJYVWnlIc4MA+EhLnDx7fjKgCqIgR4I+61Pf7eadO38hK 5qcj7dMfSdNn7GhaiFF2I9Jhz1F0tN0iDuBqBQpbFUfFt/3wsZNqJegAEYYmzDAHsXBK 2+jAS9tRrWClQZ/1Q8VdrKPsHyk2CVONMMHlCOhN9PNv6dREaolVxU+GNtaV+p7Jers6 NfRnY32/GSNG9mWIus05oMa6NyfiAHiJKt6Ed+Dq2Q0JcHvhPgCOoew5AMymY/moNHIr z8jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:reply-to:dkim-signature; bh=1t4LRP5kAW8XRqpj1wJe7nP5AI7g+bKmcPU7nOyMrf8=; b=SStOa9fjdSf+tpTDKl3U4RWTogEkizl42t0d4eVIz/lbvOlf0rnc+/eNlsy9PRY3yc 7AX0OjArNEVbcKQSiGmXxNZ7c4ITl36dqIqOXhf+q6L6Fad+UmkGptKI+IYLqc2zyS8P mT4iTpe1jjKav0xeEhFob67Su1uEu/j5VzxObmg2rJzQEu6XBvGCSAzuyAER1h9NmIKl iCs/Up+PhDlyiu5YDQH8UiigpX7It+V0QD8gAhHWA1AWzus0mYq9YjyXcL46Ms18GNY5 NH9TVRbH9ieqfaVp0zYBt9gnQXyxYOoDrVJ1mUm43YmBdFDPwjtUNtqWcDqJrw4FLrfl OhrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=P2q0Mo8l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q5-20020a056a00088500b0052d4197336fsi15429732pfj.370.2022.08.30.17.20.52; Tue, 30 Aug 2022 17:21:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=P2q0Mo8l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232059AbiH3X40 (ORCPT + 99 others); Tue, 30 Aug 2022 19:56:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231747AbiH3Xz6 (ORCPT ); Tue, 30 Aug 2022 19:55:58 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07C636FA35 for ; Tue, 30 Aug 2022 16:55:51 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id s8-20020a170902ea0800b00172e456031eso8776965plg.3 for ; Tue, 30 Aug 2022 16:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc; bh=1t4LRP5kAW8XRqpj1wJe7nP5AI7g+bKmcPU7nOyMrf8=; b=P2q0Mo8lxezffgZkWNz/cJGfzYrkhJsiVF4lxTC20833HawT9KSi57N35KCei492Mf R8PuhpkKkW0NfzWLri9iSdQvEu4/9tve/4YNoq3RXSIe+6wwCtvXIpAszq2PLErBCf3S Bs+VWZK8vB+VU25wwtcOOwGWS/BrofxdldwT96sZIp34HeRbvNl1bf508TfCnEoH6I1t rVwm4usJvlriahOIy8EXueYjMWN/8bVUwD3UrO7MKH0pQkoDh5F+DIMM1QKE95WnmXep bBRwSBT78xOuC4WMUP+uPKUBtGeYMID60ar0EZjunNkWegWhMIxASSeFrv+Y8BFygQcH V7WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc; bh=1t4LRP5kAW8XRqpj1wJe7nP5AI7g+bKmcPU7nOyMrf8=; b=7Wil/a+eYHbKqlazBprnQi6ZoRs3kJTDE9g+S6xwhsqdftI7YakyVXZSp8r4OPt/Iy dBYJN88MNmk8XjcEXSHEUUxQJIW7Z3lx/xvy1dqLN/e1VkSYQRdbV07/HUbiFygmge5h PfSZXCuWL819N40LyY9g8nkd5A1c5vAaq6CVTV6M/Y94eLhHZDWyLfyFwJHjLz/c4sAk yERQ4l3BCvR5V0gE/Wso/WDD8hNO/JZTtmUjQnGPXQqbHflZexkgcjmnTrf2XA5duInb Yu07CyOFyox1ZU5O191y1lzVq/GMaurNdDZ5uAx7qHVoJN7ZuD3hN7MmaleCUnwacI5j l+Ew== X-Gm-Message-State: ACgBeo0GSHwytct8GVMA5+rLiVcMPYukulkzqFPHKHUjnAh3qqotD97y vvMkQuuD4U6FL4gjPrkxHk6DQxqyIHM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:aa01:b0:172:b0dc:ba40 with SMTP id be1-20020a170902aa0100b00172b0dcba40mr23639626plb.101.1661903751484; Tue, 30 Aug 2022 16:55:51 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 30 Aug 2022 23:55:35 +0000 In-Reply-To: <20220830235537.4004585-1-seanjc@google.com> Mime-Version: 1.0 References: <20220830235537.4004585-1-seanjc@google.com> X-Mailer: git-send-email 2.37.2.672.g94769d06f0-goog Message-ID: <20220830235537.4004585-8-seanjc@google.com> Subject: [PATCH v4 7/9] KVM: x86/mmu: Track the number of TDP MMU pages, but not the actual pages From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Mingwei Zhang , Yan Zhao , Ben Gardon Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Track the number of TDP MMU "shadow" pages instead of tracking the pages themselves. With the NX huge page list manipulation moved out of the common linking flow, elminating the list-based tracking means the happy path of adding a shadow page doesn't need to acquire a spinlock and can instead inc/dec an atomic. Keep the tracking as the WARN during TDP MMU teardown on leaked shadow pages is very, very useful for detecting KVM bugs. Tracking the number of pages will also make it trivial to expose the counter to userspace as a stat in the future, which may or may not be desirable. Note, the TDP MMU needs to use a separate counter (and stat if that ever comes to be) from the existing n_used_mmu_pages. The TDP MMU doesn't bother supporting the shrinker nor does it honor KVM_SET_NR_MMU_PAGES (because the TDP MMU consumes so few pages relative to shadow paging), and including TDP MMU pages in that counter would break both the shrinker and shadow MMUs, e.g. if a VM is using nested TDP. Cc: Yan Zhao Reviewed-by: Mingwei Zhang Reviewed-by: David Matlack Signed-off-by: Sean Christopherson --- arch/x86/include/asm/kvm_host.h | 11 +++-------- arch/x86/kvm/mmu/tdp_mmu.c | 20 +++++++++----------- 2 files changed, 12 insertions(+), 19 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 48e51600f1be..6c2113e6d19c 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1282,6 +1282,9 @@ struct kvm_arch { */ bool tdp_mmu_enabled; + /* The number of TDP MMU pages across all roots. */ + atomic64_t tdp_mmu_pages; + /* * List of struct kvm_mmu_pages being used as roots. * All struct kvm_mmu_pages in the list should have @@ -1302,18 +1305,10 @@ struct kvm_arch { */ struct list_head tdp_mmu_roots; - /* - * List of struct kvmp_mmu_pages not being used as roots. - * All struct kvm_mmu_pages in the list should have - * tdp_mmu_page set and a tdp_mmu_root_count of 0. - */ - struct list_head tdp_mmu_pages; - /* * Protects accesses to the following fields when the MMU lock * is held in read mode: * - tdp_mmu_roots (above) - * - tdp_mmu_pages (above) * - the link field of struct kvm_mmu_pages used by the TDP MMU * - possible_nx_huge_pages; * - the possible_nx_huge_page_link field of struct kvm_mmu_pages used diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index fd38465aee9e..92ad533f4f25 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -29,7 +29,6 @@ int kvm_mmu_init_tdp_mmu(struct kvm *kvm) kvm->arch.tdp_mmu_enabled = true; INIT_LIST_HEAD(&kvm->arch.tdp_mmu_roots); spin_lock_init(&kvm->arch.tdp_mmu_pages_lock); - INIT_LIST_HEAD(&kvm->arch.tdp_mmu_pages); kvm->arch.tdp_mmu_zap_wq = wq; return 1; } @@ -54,7 +53,7 @@ void kvm_mmu_uninit_tdp_mmu(struct kvm *kvm) /* Also waits for any queued work items. */ destroy_workqueue(kvm->arch.tdp_mmu_zap_wq); - WARN_ON(!list_empty(&kvm->arch.tdp_mmu_pages)); + WARN_ON(atomic64_read(&kvm->arch.tdp_mmu_pages)); WARN_ON(!list_empty(&kvm->arch.tdp_mmu_roots)); /* @@ -377,11 +376,13 @@ static void handle_changed_spte_dirty_log(struct kvm *kvm, int as_id, gfn_t gfn, static void tdp_account_mmu_page(struct kvm *kvm, struct kvm_mmu_page *sp) { kvm_account_pgtable_pages((void *)sp->spt, +1); + atomic64_inc(&kvm->arch.tdp_mmu_pages); } static void tdp_unaccount_mmu_page(struct kvm *kvm, struct kvm_mmu_page *sp) { kvm_account_pgtable_pages((void *)sp->spt, -1); + atomic64_dec(&kvm->arch.tdp_mmu_pages); } /** @@ -397,17 +398,17 @@ static void tdp_mmu_unlink_sp(struct kvm *kvm, struct kvm_mmu_page *sp, bool shared) { tdp_unaccount_mmu_page(kvm, sp); + + if (!sp->nx_huge_page_disallowed) + return; + if (shared) spin_lock(&kvm->arch.tdp_mmu_pages_lock); else lockdep_assert_held_write(&kvm->mmu_lock); - list_del(&sp->link); - - if (sp->nx_huge_page_disallowed) { - sp->nx_huge_page_disallowed = false; - untrack_possible_nx_huge_page(kvm, sp); - } + sp->nx_huge_page_disallowed = false; + untrack_possible_nx_huge_page(kvm, sp); if (shared) spin_unlock(&kvm->arch.tdp_mmu_pages_lock); @@ -1145,9 +1146,6 @@ static int tdp_mmu_link_sp(struct kvm *kvm, struct tdp_iter *iter, tdp_mmu_set_spte(kvm, iter, spte); } - spin_lock(&kvm->arch.tdp_mmu_pages_lock); - list_add(&sp->link, &kvm->arch.tdp_mmu_pages); - spin_unlock(&kvm->arch.tdp_mmu_pages_lock); tdp_account_mmu_page(kvm, sp); return 0; -- 2.37.2.672.g94769d06f0-goog