From patchwork Tue May 9 13:52:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yan Zhao X-Patchwork-Id: 91610 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2929234vqo; Tue, 9 May 2023 07:29:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6BjStvFTLkuiJUaVmF+E7ODDGG2Wo95xkfNACykuopUCeeI6Inz2azV++Kkn29jMDHamLv X-Received: by 2002:a17:90b:3701:b0:24e:5fe6:76e8 with SMTP id mg1-20020a17090b370100b0024e5fe676e8mr14277582pjb.15.1683642583604; Tue, 09 May 2023 07:29:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683642583; cv=none; d=google.com; s=arc-20160816; b=YUbL3f2+SlNGz5zM96h6Z4/4uJj5I6lqkMjw00SJi5tDOd9AExQJjbjgDZIr19sqN9 SpzZ8MeevP9uUAtBC9xCtoPXHSglLX3pAWxusL1DBOQB6JPdPm7a3OPQ2DXN12Wssta/ SxCWIWNqdMinNUAxT8xQJXNy8DuiadcakSG/lbYCjDwvxrcYZq/9o0hRiQgm3VcSWXGh cZe+uP4Ks61oLqsXyOJKRwoNzwehpZT7ud4VRSPSaRWAO95HWwUAPVYiG7Bh+xvzOBYq UfNMBCYF+qTRyf+70JVErOP6stGu1bITWIX5QCGROlSOpEwfmiVtcwFtoi9MOUS/Gmno 3FPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=Dtz7YtHn6/fykIum9Gq0QFV3iXd7b+YwEsR5QT7Xo7I=; b=UnKboY0XgXCexBwbhd5UPNICQXHqPYjlBYLLAjge2BFuf/kPRpoXs/Ov0yW4spbY/z 6APXv2ECxfo9A0rH9WlrHZqAfb+3AWpr0Sq6EjigYPTtRbzGypuScgnk3ov0mwRVeRsL mpTV1ghPpT/ErzSzgUGxnCR8M/M7QLVHjh4SmE2iVv67Yuhtem7LBYwV0zXoKpq3nPJU pooVSDJM0RMfCqTHS9jiLtwJIcjnVY8mfWXQGN4o0Sie6HnyMI2SIwCsAC6S3R9in2LG jsNYzDwc+06AY/QUyb0gLlJJqZLLwtvwIlL+DT7QmGoSXcMtpbwgHt9CMWDbjcYKarhD yeCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TAwZ28Zp; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l2-20020a17090aec0200b0024e0758c190si19841218pjy.27.2023.05.09.07.29.28; Tue, 09 May 2023 07:29:43 -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=@intel.com header.s=Intel header.b=TAwZ28Zp; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235830AbjEIOUP (ORCPT + 99 others); Tue, 9 May 2023 10:20:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235013AbjEIOUK (ORCPT ); Tue, 9 May 2023 10:20:10 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14E9430F7; Tue, 9 May 2023 07:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1683642008; x=1715178008; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=9k7MFPNbtv2QzGAeGYaRb/Sks6eG/baaVVfpJ4EEOVA=; b=TAwZ28ZpljasI4j5n1yrYBvKHgIno+0z4VU/hZXSFat3g0CQztoeNLKl K7qM1y5QTnIHXi+RLX9rRbKEWCbbr+SpuaqerOm9CpgTskInSMZsyzVi6 OZ1CG5dpMmPT7fNqSX+ZH8pUBAbrLSXl+PdzVVZO2/ja+Oug7ZgEycyrE 7wuk9+xlR5z7FqLmYSAxPQJYe5rs/xuAy86pQRmG30eFuvhFnJKNbWouu CBwecy9qdq/JgD3ICDVGpPDHcAWIXFf3+RR+bSgCIimFyHI0Mv63CdHE5 fJaIrL22+Ta/tfDobrtwf5AaaU4s4HfXluSecLq5IFpbDaUX26FS2/eZO Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10705"; a="329561785" X-IronPort-AV: E=Sophos;i="5.99,262,1677571200"; d="scan'208";a="329561785" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2023 07:17:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10705"; a="823114077" X-IronPort-AV: E=Sophos;i="5.99,262,1677571200"; d="scan'208";a="823114077" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2023 07:17:24 -0700 From: Yan Zhao To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: pbonzini@redhat.com, seanjc@google.com, Yan Zhao Subject: [PATCH v2 4/6] KVM: x86/mmu: Zap all EPT leaf entries according noncoherent DMA count Date: Tue, 9 May 2023 21:52:26 +0800 Message-Id: <20230509135226.1780-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230509134825.1523-1-yan.y.zhao@intel.com> References: <20230509134825.1523-1-yan.y.zhao@intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765427205732725830?= X-GMAIL-MSGID: =?utf-8?q?1765427205732725830?= Zap all EPT leaf entries when noncoherent DMA count goes from 0 to 1, or from 1 to 0. When there's no noncoherent DMA device, EPT memory type is ((MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT) When there're noncoherent DMA devices, EPT memory type needs to honor guest CR0_CD and MTRR settings. So, if noncoherent DMA count changes between 0 and 1, EPT leaf entries need to be zapped to clear stale memory type. This issue might be hidden when the device is statically assigned with VFIO adding/removing MMIO regions of the noncoherent DMA devices for several times during guest boot, and current KVM MMU will call kvm_mmu_zap_all_fast() on the memslot removal. But if the device is hot-plugged, or if the guest has mmio_always_on for the device, the MMIO regions of it may only be added for once, then there's no path to do the EPT entries zapping to clear stale memory type. Therefore do the EPT zapping of all leaf entries when present/non-present state of noncoherent DMA devices changes to ensure stale entries cleaned away. Signed-off-by: Yan Zhao --- arch/x86/kvm/x86.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ed1e3939bd05..48b683a305b3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -13145,13 +13145,15 @@ EXPORT_SYMBOL_GPL(kvm_arch_has_assigned_device); void kvm_arch_register_noncoherent_dma(struct kvm *kvm) { - atomic_inc(&kvm->arch.noncoherent_dma_count); + if (atomic_inc_return(&kvm->arch.noncoherent_dma_count) == 1) + kvm_zap_gfn_for_memtype(kvm, gpa_to_gfn(0), gpa_to_gfn(~0ULL)); } EXPORT_SYMBOL_GPL(kvm_arch_register_noncoherent_dma); void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm) { - atomic_dec(&kvm->arch.noncoherent_dma_count); + if (!atomic_dec_return(&kvm->arch.noncoherent_dma_count)) + kvm_zap_gfn_for_memtype(kvm, gpa_to_gfn(0), gpa_to_gfn(~0ULL)); } EXPORT_SYMBOL_GPL(kvm_arch_unregister_noncoherent_dma);