From nobody Wed Sep 17 06:41:37 2025 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 6D4FCC001DE for ; Sat, 29 Jul 2023 01:37:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234889AbjG2BhW (ORCPT ); Fri, 28 Jul 2023 21:37:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237597AbjG2BhI (ORCPT ); Fri, 28 Jul 2023 21:37:08 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EA6F49DE for ; Fri, 28 Jul 2023 18:36:37 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-5634dbfb8b1so1696430a12.1 for ; Fri, 28 Jul 2023 18:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690594568; x=1691199368; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=LElPg6EV64u55H7Mf5AyrdjNlx5IOWlBkIPEppU8Jnw=; b=jfCkSXMvNm0a4r+jhBUQwEXZDOxflF3V10465oegx122JX3cMjyBQ9B6yH6wk+0Jzp UVY6dLZfCVQ0+FBwRm/X8oVmEgDEuMdMqkJVU/heWBSTLawPW9MjAzRT+N1Ynxg/SZNT KNqx0RkGgbjKNuutmmNxcjNPUVwHvZRAkFFuiWse/LAAXFpfuTolirdvvmrpgdLdTv4u Z4LbCo1VWeYHuIu/i1dW/gchrcve2Xo01BA20So28O333O53tZVGRyVXESvsCZFJCXwh 1d9D4TzpmXEjyMHr15owgr2TNH+L6sDCDTgxWySgb2terfpz4qAARImLY+CUy17C8wlM P1Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690594568; x=1691199368; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LElPg6EV64u55H7Mf5AyrdjNlx5IOWlBkIPEppU8Jnw=; b=hGkLsRPSMn7Ixsf0Mb+Cx/royIK2a6rpCVSIrx7yA2baMaQXLvEUohxQ+uFj+qpBlp x5TutXVwaZ2X1KIhkdQC24ZN9SfNJblDUn4gv4P/TMb+NRD1lntQ4Bau1ZFuDvHhS8+v FeqvmqBnOp/kU+gro2j9tBB544JlYHfNa9ADQE/96FzvIjkAiWoKGbyuaVXANXi7TSpf ZvN9zf52UDZux3cE7utySUln4Z+lvsKmz+4PtAWvwq90uk9CI+ZU1yqKJtk1izoXGcJS nrTZjWauHbOgs21gVIwHSO/KeV+XDGm+84m8ajYdyX5JrEt5RNmGP2AKFGwQL9kUrFUg W1TA== X-Gm-Message-State: ABy/qLau6hLC43e2D2xHH3/ui4Gio/I26PcRU7pmfO6n49WzjNJXx7L4 n7W5/TbkIez8lzA3Vr+OxIOI9GJLr8A= X-Google-Smtp-Source: APBJJlFvu/5rgdRg5jWuo0EZYVBoATZTGEN5oN8JxS8hlpYglyUmwtlAU4FlgtZH1W7tOI6Tno2qFTm78ZM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:c406:b0:1b8:3c5e:2289 with SMTP id k6-20020a170902c40600b001b83c5e2289mr12198plk.2.1690594568714; Fri, 28 Jul 2023 18:36:08 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 28 Jul 2023 18:35:19 -0700 In-Reply-To: <20230729013535.1070024-1-seanjc@google.com> Mime-Version: 1.0 References: <20230729013535.1070024-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog Message-ID: <20230729013535.1070024-14-seanjc@google.com> Subject: [PATCH v4 13/29] KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot change From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini , Zhenyu Wang , Zhi Wang Cc: kvm@vger.kernel.org, intel-gvt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Yan Zhao , Yongwei Ma , Ben Gardon Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Call kvm_mmu_zap_all_fast() directly when flushing a memslot instead of bouncing through the page-track mechanism. KVM (unfortunately) needs to zap and flush all page tables on memslot DELETE/MOVE irrespective of whether KVM is shadowing guest page tables. This will allow changing KVM to register a page-track notifier on the first shadow root allocation, and will also allow deleting the misguided kvm_page_track_flush_slot() hook itself once KVM-GT also moves to a different method for reacting to memslot changes. No functional change intended. Cc: Yan Zhao Link: https://lore.kernel.org/r/20221110014821.1548347-2-seanjc@google.com Reviewed-by: Yan Zhao Tested-by: Yongwei Ma Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/mmu.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index c6dee659d592..79ea57396d97 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6199,13 +6199,6 @@ static bool kvm_has_zapped_obsolete_pages(struct kvm= *kvm) return unlikely(!list_empty_careful(&kvm->arch.zapped_obsolete_pages)); } =20 -static void kvm_mmu_invalidate_zap_pages_in_memslot(struct kvm *kvm, - struct kvm_memory_slot *slot, - struct kvm_page_track_notifier_node *node) -{ - kvm_mmu_zap_all_fast(kvm); -} - int kvm_mmu_init_vm(struct kvm *kvm) { struct kvm_page_track_notifier_node *node =3D &kvm->arch.mmu_sp_tracker; @@ -6223,7 +6216,6 @@ int kvm_mmu_init_vm(struct kvm *kvm) } =20 node->track_write =3D kvm_mmu_pte_write; - node->track_flush_slot =3D kvm_mmu_invalidate_zap_pages_in_memslot; kvm_page_track_register_notifier(kvm, node); =20 kvm->arch.split_page_header_cache.kmem_cache =3D mmu_page_header_cache; @@ -6765,6 +6757,8 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm) void kvm_arch_flush_shadow_memslot(struct kvm *kvm, struct kvm_memory_slot *slot) { + kvm_mmu_zap_all_fast(kvm); + kvm_page_track_flush_slot(kvm, slot); } =20 --=20 2.41.0.487.g6d72f3e995-goog