Message ID | 20230714064656.20147-1-yan.y.zhao@intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp2340964vqm; Fri, 14 Jul 2023 00:54:25 -0700 (PDT) X-Google-Smtp-Source: APBJJlEVOk1ZiZy5HUQhwxSz/UbGu4iWNzUdM9jY8tN/FLXr6Y13D3zFvokbNzFy30HzKtMHHa5M X-Received: by 2002:a05:6512:32d1:b0:4f8:6800:86f6 with SMTP id f17-20020a05651232d100b004f8680086f6mr4073232lfg.49.1689321265137; Fri, 14 Jul 2023 00:54:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689321265; cv=none; d=google.com; s=arc-20160816; b=uNck8ONpXf1MXSrMUIkYjz3cwBWApxbxZWHqamF0AtwzXxGQsGsW7QnDQUphd/AWvo mtLAcneQraa3gxeQqNrk4M68AJPyCI80KmGkEdWZMfwUy9uBLM903+rQMZUwMN+LbmOb kpDNpAKSdArARE21+04/9UTa/GCwswcVHqQsrMpSaAesmxAEWWJQi8zKGy3akrAW6ugF B8NkdsK5m67Wsz9WMcc46JoeDj2Uc05ys2Ya7sfcAAiJsFU/cz24WXFUe5RbUQXIJ4iP gWni/fHE/ekp/gZFCx1TRc/saTWb6aR/mMc8LCyU7edA4PAPDNlAPf/IvuKsuNdGYnzl iY+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=AtSAk9wXiOtlQzLtrFIKiThjiLa21EA5bmWyljgFg5w=; fh=I6wrbN01dP2yWc/eoJu3Jm+A24tUYxebxIQloyExA+I=; b=MROvOa+K/Qcjs+2ES+8a0HzRmFyEycd8uuk13kV2A5Iyl6rUgKrdkeT3BinyUX8oXB BeeK6qyXue3tBDJVsmtqqtgmTpKUbDP1W6P+bhTo5+m8juRUA4q+8RJ6AC8NREgWRtVo SpgOfU4/na5K1LnlPsPfgOB1jNvmzGjbvLMzwUybdPuQv+yFs3zlvy2rKMqv+3+kpcze ATIvH8JLXIIFd6SZmf9Pr1C34sMewspkMxLlWL0Wf1PoAX3kGGyYJuD9RmEM4IsQrdsM kqSwVROZYFpl3vsJF8IalUiNfg4Nzanh4VlIkhgseBOQUZO9UZtlh87dLPKrZNO/cs6R 50Gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=M8jfZbGD; 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 b3-20020aa7cd03000000b0051be8be77afsi8452664edw.145.2023.07.14.00.53.56; Fri, 14 Jul 2023 00:54:25 -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=M8jfZbGD; 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 S235314AbjGNHOn (ORCPT <rfc822;hadasmailinglist@gmail.com> + 99 others); Fri, 14 Jul 2023 03:14:43 -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 <rfc822;linux-kernel@vger.kernel.org>); 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 <yan.y.zhao@intel.com> 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 <yan.y.zhao@intel.com> 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 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1768827685592437760 X-GMAIL-MSGID: 1771381734555650372 |
Series |
KVM: x86/mmu: refine memtype related mmu zap
|
|
Message
Yan Zhao
July 14, 2023, 6:46 a.m. UTC
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
Comments
On Fri, 14 Jul 2023 14:46:56 +0800, Yan Zhao wrote: > 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. > > [...] Applied 1-5 and 7 to kvm-x86 mmu. I squashed 1 and 2 as introducing helpers to consolidate existing code without converting the existing code is wierd and makes it unnecessarily impossible to properly test the helpers when they're added. I skipped 6, "move TDP zaps from guest MTRRs update to CR0.CD toggling", for now as your performance numbers showed that it slowed down the guest even though the number of zaps went down. I'm definitely not against the patch, I just don't want to risk regressing guest performance, i.e. I don't wantt to take it without the rest of the series that takes advantage of the change. I massaged a few shortlogs and changelogs, but didn't touch any code. Holler if anything looks funky. Thanks much! [1/5] KVM: x86/mmu: Add helpers to return if KVM honors guest MTRRs https://github.com/kvm-x86/linux/commit/6590a37e7ec6 [2/5] KVM: x86/mmu: Zap SPTEs when CR0.CD is toggled iff guest MTRRs are honored https://github.com/kvm-x86/linux/commit/c0ad4a14c5af [3/5] KVM: x86/mmu: Zap SPTEs on MTRR update iff guest MTRRs are honored https://github.com/kvm-x86/linux/commit/a1596812cce1 [4/5] KVM: x86/mmu: Xap KVM TDP when noncoherent DMA assignment starts/stops https://github.com/kvm-x86/linux/commit/3c4955c04b95 [5/5] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED https://github.com/kvm-x86/linux/commit/f7b4bcd501ef -- https://github.com/kvm-x86/linux/tree/next
On Wed, 2023-10-04 at 18:29 -0700, Sean Christopherson wrote: > [4/5] KVM: x86/mmu: Xap KVM TDP when noncoherent DMA assignment starts/stops > https://github.com/kvm-x86/linux/commit/3c4955c04b95 Xap -> Zap? :-) Apologize if I missed something.
On Thu, Oct 05, 2023, Kai Huang wrote: > On Wed, 2023-10-04 at 18:29 -0700, Sean Christopherson wrote: > > [4/5] KVM: x86/mmu: Xap KVM TDP when noncoherent DMA assignment starts/stops > > https://github.com/kvm-x86/linux/commit/3c4955c04b95 > > Xap -> Zap? :-) Dagnabbit, I tried to capitalize z => Z and hit the wrong key. I'll fixup. Thanks Kai!
On Wed, Oct 04, 2023, Sean Christopherson wrote: > On Thu, Oct 05, 2023, Kai Huang wrote: > > On Wed, 2023-10-04 at 18:29 -0700, Sean Christopherson wrote: > > > [4/5] KVM: x86/mmu: Xap KVM TDP when noncoherent DMA assignment starts/stops > > > https://github.com/kvm-x86/linux/commit/3c4955c04b95 > > > > Xap -> Zap? :-) > > Dagnabbit, I tried to capitalize z => Z and hit the wrong key. I'll fixup. LOL, the real irony is that this particular patch also has this in the changelog: [sean: fix misspelled words in comment and changelog] Anyways, fixed. New hashes are: [4/5] KVM: x86/mmu: Zap KVM TDP when noncoherent DMA assignment starts/stops https://github.com/kvm-x86/linux/commit/539c103e2a13 [5/5] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED https://github.com/kvm-x86/linux/commit/10ed442fefdd