From patchwork Fri Jul 14 06:46:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yan Zhao X-Patchwork-Id: 13313029 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 A159BEB64DC for ; Fri, 14 Jul 2023 07:14:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235317AbjGNHOm (ORCPT ); Fri, 14 Jul 2023 03:14:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235287AbjGNHOj (ORCPT ); Fri, 14 Jul 2023 03:14:39 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8D3F2D61; Fri, 14 Jul 2023 00:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689318870; x=1720854870; h=from:to:cc:subject:date:message-id; bh=O9jnJ5j3krm419hqh5DB2huVZuUSyj8Ki0+dAkw19FQ=; b=M8jfZbGDFHJEdm2A49IXsEQ9g/LfCBUoZ53xJMiVrzyiNfZqLoHud7E1 Jp3EzOr+7GwQB+fgjPcAQRZQUJq6Y4L6JI/Z9R/RdVvgofBlUWdgi/WmC 75nRrINr/tQuLxSBkn3HYzNO0ooYP1DHldB2/EVWlD6Tap8gZeese7oR5 mFhXi9V+QjgimO9p9vv7rWwZxJEguSZVhOya4TIaaMiKga6kslrlB6Kfg Rxj9uBMa5bfS+RssySYZ0C1vDsSJygrOyIjeEqM8MVmZcROTBMiRyiV/E p6a8F2HUndJo5uAxDLqQpLiXF90IfeuHF6/r9R8XSUS8X/oMxhGpKAmPZ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="355348168" X-IronPort-AV: E=Sophos;i="6.01,204,1684825200"; d="scan'208";a="355348168" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2023 00:14:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="757475076" X-IronPort-AV: E=Sophos;i="6.01,204,1684825200"; d="scan'208";a="757475076" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2023 00:14:27 -0700 From: Yan Zhao To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: pbonzini@redhat.com, seanjc@google.com, chao.gao@intel.com, kai.huang@intel.com, robert.hoo.linux@gmail.com, yuan.yao@linux.intel.com, Yan Zhao Subject: [PATCH v4 00/12] KVM: x86/mmu: refine memtype related mmu zap Date: Fri, 14 Jul 2023 14:46:56 +0800 Message-Id: <20230714064656.20147-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org This series refines mmu zap caused by EPT memory type update when guest MTRRs are honored. Patches 1-5 revolve around utilizing helper functions to check if KVM TDP honors guest MTRRs, TDP zaps and page fault max_level reduction are now only targeted to TDPs that honor guest MTRRs. -The 5th patch will trigger zapping of TDP leaf entries if non-coherent DMA devices count goes from 0 to 1 or from 1 to 0. Patches 6-7 are fixes and patches 9-12 are optimizations for mmu zaps when guest MTRRs are honored. Those mmu zaps are intended to remove stale memtypes of TDP entries caused by changes of guest MTRRs and CR0.CD and are usually triggered from all vCPUs in bursts. - The 6th patch places TDP zap to when CR0.CD toggles and when guest MTRRs update under CR0.CD=0. - The 7th-8th patches refine KVM_X86_QUIRK_CD_NW_CLEARED by removing the IPAT bit in EPT memtype when CR0.CD=1 and guest MTRRs are honored. - The 9th-11th patches are optimizations of the mmu zap when guest MTRRs are honored by serializing vCPUs' gfn zap requests and calculating of precise fine-grained ranges to zap. They are put in mtrr.c because the optimizations are related to when guest MTRRs are honored and because it requires to read guest MTRRs for fine-grained ranges. Calls to kvm_unmap_gfn_range() are not included into the optimization, because they are not triggered from all vCPUs in bursts and not all of them are blockable. They usually happen at memslot removal and thus do not affect the mmu zaps when guest MTRRs are honored. Also, current performance data shows that there's no observable performance difference to mmu zaps by turning on/off auto numa balancing triggered kvm_unmap_gfn_range(). - The 12th patch further convert kvm_zap_gfn_range() to use shared mmu_lock in TDP MMU. It can visibly help to reduce cost in contentions along with vCPUs number increases. A reference performance data for last 7 patches as below: Base1: base code before patch 6 Base2: Base 1 + patches 6 + 7 + 8 patch 6: move TDP zaps from guest MTRRs update to CR0.CD toggling patch 7: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED patch 8: entralize code to get CD=1 memtype when guest MTRRs are honored patch 9: serialize gfn zap patch 10: fine-grained gfn zap patch 11: split and zap in-slot gfn ranges only ** patch 12: convert gfn zap to use shared mmu_lock