From mboxrd@z Thu Jan 1 00:00:00 1970 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 71DB9C6FA82 for ; Tue, 13 Sep 2022 12:59:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231911AbiIMM7F (ORCPT ); Tue, 13 Sep 2022 08:59:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231406AbiIMM7B (ORCPT ); Tue, 13 Sep 2022 08:59:01 -0400 Received: from out0-152.mail.aliyun.com (out0-152.mail.aliyun.com [140.205.0.152]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCE9C41D20; Tue, 13 Sep 2022 05:58:47 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R981e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047211;MF=houwenlong.hwl@antgroup.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---.PEZ9oUN_1663073913; Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.PEZ9oUN_1663073913) by smtp.aliyun-inc.com; Tue, 13 Sep 2022 20:58:33 +0800 Date: Tue, 13 Sep 2022 20:58:33 +0800 From: "Hou Wenlong" To: David Matlack Cc: kvm@vger.kernel.org, Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 6/6] KVM: x86/mmu: Use 1 as the size of gfn range for tlb flushing in FNAME(invlpg)() Message-ID: <20220913125833.GC113257@k08j02272.eu95sqa> References: <8baa40dad8496abb2adb1096e0cf50dcc5f66802.1661331396.git.houwenlong.hwl@antgroup.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 08, 2022 at 01:40:16AM +0800, David Matlack wrote: > On Wed, Aug 24, 2022 at 05:29:23PM +0800, Hou Wenlong wrote: > > Only SP with PG_LEVLE_4K level could be unsync, so the size of gfn range > > must be 1. > > > > Signed-off-by: Hou Wenlong > > --- > > arch/x86/kvm/mmu/paging_tmpl.h | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h > > index 04149c704d5b..486a3163b1e4 100644 > > --- a/arch/x86/kvm/mmu/paging_tmpl.h > > +++ b/arch/x86/kvm/mmu/paging_tmpl.h > > @@ -937,7 +937,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa) > > > > mmu_page_zap_pte(vcpu->kvm, sp, sptep, NULL); > > if (is_shadow_present_pte(old_spte)) > > - kvm_flush_remote_tlbs_sptep(vcpu->kvm, sptep); > > + kvm_flush_remote_tlbs_gfn(vcpu->kvm, > > + kvm_mmu_page_get_gfn(sp, sptep - sp->spt), 1); > > The third argument to kvm_flush_remote_tlbs_gfn() is the level, not the > number of pages. But that aside, I don't understand why this patch is > necessary. kvm_flush_remote_tlbs_sptep() should already do the right > thing. > Since only SP with PG_LEVEL_4K level could be unsync, so the level must be PG_LEVEL_4K, then sp->role.level access could be dropped. However, I'm not sure whether it is useful. I can drop it if it is useless. > > > > if (!rmap_can_add(vcpu)) > > break; > > -- > > 2.31.1 > >