Message ID | 20230618000856.1714902-4-mizhang@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2218974vqr; Sat, 17 Jun 2023 17:11:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7NKWYrLFjOc4ChydYc2kyQV9XF2+U3mXgXcD/vavEq1QBuA3Ckhgb27+wJDYQhayKDqnBQ X-Received: by 2002:a05:6a00:1a56:b0:65b:38b2:8d4b with SMTP id h22-20020a056a001a5600b0065b38b28d4bmr8328127pfv.29.1687047073088; Sat, 17 Jun 2023 17:11:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687047073; cv=none; d=google.com; s=arc-20160816; b=dmpPcsq8l4CLOWHW/QF2hlSc1ANqwu9LnaphbMtOwsnQfmpGRNT2jBSMC5xbSTBP/m YimnMF3WGlGMhAG7JpAyU3Piv3RBv1ezL6Z0RiQwWy+DIhjEiWNceyBPPw3Aj43HLE+2 neHVKbI9V5SIZCdMw8GJtQqbFrCY78NQtHAlgZ+ZPTN7RfUYL5FOLxnPAIzLQVgnX7Oj 3sO6UND4MiCLTNR4E0Qd4Sq5gMVGimDa8eIJS5wMQ3WOEilV+czyBd0sNXul1EDSjSMK F6Q3V+5twh4vauiBM2ihwGVouXVwCzcgKV4mfmvSbAGKQbPljOCNrkSqmbW/UBpTry3L bgtg== 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=SWUWH2lvAYfFJm9Hx/6bdaK1OOQ3GRc/IjgAVTyvQ3A=; b=FovgdbcmPg0Nr9Mo93G8+ajEtp6+OwsyJq4DXpxj6rWN0u1ftkI3hIA5nWFFkI3fr6 CAx6IGaxVrKlkJIiBv9yexhknfNDdoXFWbVqcY0/zmM4m5uMkg/m1rRhZnRD1e+WR/5J 8lCm2TCNuPvC+VivDQgcqievgaUVyCiyBl8HnHbNQYv2u/fj9ihXXt7/xjJubBWRjwka AE5O8Y0VUGdj6J5UIx2pUCICrsDIbtxdMNePRZdBVAZgsR1mLnlXh6jkWZDKa+okO3aV QO4P3ZwrJ/G3lsnk9R52k/hsKOFPorCXXS6vsfqf3HYt/wJRDIO730iH8AMa/Abt/CBP 7vUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=30sbRvHS; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c80-20020a621c53000000b00668718e54c6si733392pfc.202.2023.06.17.17.10.59; Sat, 17 Jun 2023 17:11:13 -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=20221208 header.b=30sbRvHS; 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 S233473AbjFRAJX (ORCPT <rfc822;duw91626@gmail.com> + 99 others); Sat, 17 Jun 2023 20:09:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232271AbjFRAJT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 17 Jun 2023 20:09:19 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0496170E for <linux-kernel@vger.kernel.org>; Sat, 17 Jun 2023 17:09:17 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id d2e1a72fcca58-666ecb21fb8so1228893b3a.1 for <linux-kernel@vger.kernel.org>; Sat, 17 Jun 2023 17:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687046957; x=1689638957; 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=SWUWH2lvAYfFJm9Hx/6bdaK1OOQ3GRc/IjgAVTyvQ3A=; b=30sbRvHSEui1YuUerrYqr2XHk9jphndeiTUEpOhR4E/MjyMQ1vFoouVxAiTi+cWC2b z68RRVMYzKkyMcAJOFe9blpf8xgZ8aCKYV/bLeBkqCGnAYyF+I2DklMOG9N1+BvZnfdu wfyveTLvxnSK7i5/yPlXLgYGxmgdAxy6dmsWfAy3EwaEkNPHPb39w1nH1Vs6X+W0iXFC BQ7C5nEuqvgBVkKP7Sfb/2gv7rR5lbOsr+lTA9UnW0phq1AzQFgGDzruoKEnJsqowt8e v80Te8LKsZJf0Fvy4Y4zuIkUzFA+UHI/AsSBvfilqKtD4FLzAZAWaSxbeOOFjebG9hn/ PdVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687046957; x=1689638957; 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=SWUWH2lvAYfFJm9Hx/6bdaK1OOQ3GRc/IjgAVTyvQ3A=; b=jhb8Uj1x9jNWRnVR1FYg6g3R0FD/vL4aQUX5K2bYD/FZUfK3HjaUzQ9e1J2FuciDSD 4XlYuyGZvLPydtnk4ta8rnZx/cCHY25GMlPKe3ZzdLFQ4twA/PptMxOWCl7o9bZBs1Yg CbLRGQsz0u5zN8WkYded6oYCTlixmrXL9nXUHcop6K/hX1PSMWhKdZ4c+xr3tSgLNCmC izl7d0nUb6HSSVJ2UDlIGcyp0FdZ+O4vsHWCNYN7oKI74dP1OSLDmFiulDNUUyuE7hJY eTM3ti88SldWFgE36yc7CwCXBijfCCM5/Jwgmi0aXn4rwHBwnVzgrPckjh7M7XVdgaBI HYKg== X-Gm-Message-State: AC+VfDwNb0wyU5dYZwSOkXdH8HvUGj98qjwyATnhqlnkkOzPsQ7J2oLM ggPnD8DuvI2gtuCtmJkrsu/lO+Gex74M X-Received: from mizhang-super.c.googlers.com ([34.105.13.176]) (user=mizhang job=sendgmr) by 2002:a05:6a00:1789:b0:643:a542:b311 with SMTP id s9-20020a056a00178900b00643a542b311mr1764182pfg.0.1687046957241; Sat, 17 Jun 2023 17:09:17 -0700 (PDT) Reply-To: Mingwei Zhang <mizhang@google.com> Date: Sun, 18 Jun 2023 00:08:53 +0000 In-Reply-To: <20230618000856.1714902-1-mizhang@google.com> Mime-Version: 1.0 References: <20230618000856.1714902-1-mizhang@google.com> X-Mailer: git-send-email 2.41.0.162.gfafddb0af9-goog Message-ID: <20230618000856.1714902-4-mizhang@google.com> Subject: [PATCH 3/6] KVM: Documentation: Add the missing ptep in kvm_mmu_page From: Mingwei Zhang <mizhang@google.com> To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Mingwei Zhang <mizhang@google.com>, Jim Mattson <jmattson@google.com>, David Matlack <dmatlack@google.com>, Ben Gardon <bgardon@google.com> 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=unavailable 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768997071819599048?= X-GMAIL-MSGID: =?utf-8?q?1768997071819599048?= |
Series |
KVM: Documentation: Update document description for kvm_mmu_page and kvm_mmu_page_role
|
|
Commit Message
Mingwei Zhang
June 18, 2023, 12:08 a.m. UTC
Add the missing ptep in kvm_mmu_page description. ptep is used when TDP MMU
is enabled and it shares the storage with parent_ptes. Update the doc to
help readers to get up-to-date info.
Signed-off-by: Mingwei Zhang <mizhang@google.com>
---
Documentation/virt/kvm/x86/mmu.rst | 4 ++++
1 file changed, 4 insertions(+)
Comments
On Sun, 2023-06-18 at 00:08 +0000, Mingwei Zhang wrote: > Add the missing ptep in kvm_mmu_page description. ptep is used when TDP MMU > is enabled and it shares the storage with parent_ptes. Update the doc to > help readers to get up-to-date info. > > Signed-off-by: Mingwei Zhang <mizhang@google.com> > --- > Documentation/virt/kvm/x86/mmu.rst | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst > index 149dd3cba48f..36bfe0fe02bb 100644 > --- a/Documentation/virt/kvm/x86/mmu.rst > +++ b/Documentation/virt/kvm/x86/mmu.rst > @@ -236,6 +236,10 @@ Shadow pages contain the following information: > parent_ptes points at this single spte, otherwise, there exists multiple > sptes pointing at this page and (parent_ptes & ~0x1) points at a data > structure with a list of parent sptes. > + ptep: > + Pointer to the parent spte when TDP MMU is enabled. > IMHO "parent spte" alone _may_ be confusing. I think it's better to explicitly mention "pointing to this page" similar to the "parent_ptes" above. Also, I think "when TDP MMU is enabled" isn't strictly true, depending on what does "when TDP MMU is enabled mean". E.g., when tdp_mmu_enabled module parameter is true, we can still have a nested EPT shadow page from L2 which won't use this either IIUC. > In TDP MMU, each > + shadow page will have at most one parent. Note that this field is a > + union with parent_ptes. Also, perhaps "have at most one parent" can be more precise: only root page has no parent, while other non-root pages always have one parent SPTE pointing to each of them.
On Thu, Jun 22, 2023, Huang, Kai wrote: > On Sun, 2023-06-18 at 00:08 +0000, Mingwei Zhang wrote: > > Add the missing ptep in kvm_mmu_page description. ptep is used when TDP MMU > > is enabled and it shares the storage with parent_ptes. Update the doc to > > help readers to get up-to-date info. > > > > Signed-off-by: Mingwei Zhang <mizhang@google.com> > > --- > > Documentation/virt/kvm/x86/mmu.rst | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst > > index 149dd3cba48f..36bfe0fe02bb 100644 > > --- a/Documentation/virt/kvm/x86/mmu.rst > > +++ b/Documentation/virt/kvm/x86/mmu.rst > > @@ -236,6 +236,10 @@ Shadow pages contain the following information: > > parent_ptes points at this single spte, otherwise, there exists multiple > > sptes pointing at this page and (parent_ptes & ~0x1) points at a data > > structure with a list of parent sptes. > > + ptep: > > + Pointer to the parent spte when TDP MMU is enabled. > > > > IMHO "parent spte" alone _may_ be confusing. I think it's better to explicitly > mention "pointing to this page" similar to the "parent_ptes" above. Sure. I can change the style to be consistent with the descriptions of 'parent_ptes'. > > Also, I think "when TDP MMU is enabled" isn't strictly true, depending on what > does "when TDP MMU is enabled mean". E.g., when tdp_mmu_enabled module > parameter is true, we can still have a nested EPT shadow page from L2 which > won't use this either IIUC. > hmm, "when TDP MMU is enabled" should be "when used by TDP MMU". You are right since when TDP MMU is used for L1, we may still have shadow MMUs for L2s. I modify the description. > > In TDP MMU, each > > + shadow page will have at most one parent. Note that this field is a > > + union with parent_ptes. > > Also, perhaps "have at most one parent" can be more precise: only root page has > no parent, while other non-root pages always have one parent SPTE pointing to > each of them. Will do in next version.
diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst index 149dd3cba48f..36bfe0fe02bb 100644 --- a/Documentation/virt/kvm/x86/mmu.rst +++ b/Documentation/virt/kvm/x86/mmu.rst @@ -236,6 +236,10 @@ Shadow pages contain the following information: parent_ptes points at this single spte, otherwise, there exists multiple sptes pointing at this page and (parent_ptes & ~0x1) points at a data structure with a list of parent sptes. + ptep: + Pointer to the parent spte when TDP MMU is enabled. In TDP MMU, each + shadow page will have at most one parent. Note that this field is a + union with parent_ptes. unsync: If true, then the translations in this page may not match the guest's translation. This is equivalent to the state of the tlb when a pte is