Received: by 2002:ac8:156:0:b0:3e0:cd10:60c8 with SMTP id f22csp2291619qtg; Mon, 3 Apr 2023 14:35:07 -0700 (PDT) X-Google-Smtp-Source: AKy350bJMW+3oz7lByQ7590wL7D/Z4vDpiXv5LopIVbyuJRBytfVkphl0K42ucLQUPZXrzquBrtU X-Received: by 2002:a17:902:f10c:b0:1a1:6584:31b0 with SMTP id e12-20020a170902f10c00b001a1658431b0mr443397plb.30.1680557706987; Mon, 03 Apr 2023 14:35:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680557706; cv=none; d=google.com; s=arc-20160816; b=LX5i46qeozpzuKkF2dUoOOztccFpQcm5A5EwRf9JL9y7r0KBpg7wUGHLDy+KKLygnh SdGQwQltgzX4+kv0GS7Lu5poBCgTPkWsCxxd9IdcZUdBz/lU9MTX6DVs8/ZIM1lgIQT+ HcrrlToToYIG9YHWhoZU2e5o+K4MB2LoboyZTzjLJgrYDa2D30xEnhhAJLb7dvbKJstn uDsulGXKqgKcV5OlbLeEXg9BHgrA9tMblSUl28rjBGno5g/BT3pGNwwkklQdinxSIFOP qZlcXYQAiDS1dNtL2xrn0yJOOWJE17x+lLzpKWTcwC0/FTMxlUSnZb6HCsFQjD/Qu9Wx OPBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=kj5a1Gjv5u3ed9nScVQuCJw/TrKNl0CS2e9DPpgpMXA=; b=DzjP/0jr5jr+Ba//hhihqTgMDz441fRG0UbvCT54S6ee70AdBiiWBLTvOKKqSF8qAN eBHIy3/ykGw+b1HPr460GHOrm9zM1cSy7Hg1Z0431+BJNkC5vK5TMpWJYOo5k/6EWH1m i8HwNoYR189klzL7b0jUVCEkZloV4/FGr6wsKQP/fgdn5foMNXBzsJBypAWhRKArnZAh mzHMcrOcavbh70LEnZ66fb4v5EOPukXZi5mx51wxl0CA9HiauS2+55mOfsMw9EI5WX3G NjXMBu4hfngZ7RddehZhDp1akdMmhL1PqrZlp29shVObaG1NztgJKtTt6oHMJW1/gNWR mlZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=mgVL+rEN; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w4-20020a656944000000b004fb7e7ef77dsi8820079pgq.693.2023.04.03.14.34.54; Mon, 03 Apr 2023 14:35:06 -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=20210112 header.b=mgVL+rEN; 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 S233502AbjDCV0M (ORCPT + 99 others); Mon, 3 Apr 2023 17:26:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233703AbjDCV0G (ORCPT ); Mon, 3 Apr 2023 17:26:06 -0400 Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A857746B2 for ; Mon, 3 Apr 2023 14:26:01 -0700 (PDT) Received: by mail-oo1-xc2e.google.com with SMTP id g21-20020a4ad855000000b0053e563c2f72so3661296oov.6 for ; Mon, 03 Apr 2023 14:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680557161; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kj5a1Gjv5u3ed9nScVQuCJw/TrKNl0CS2e9DPpgpMXA=; b=mgVL+rENIqJd9I9v7V0Guir9ljCZePQyRnCXisG5f1mOrzACjXVqszlL/X48Vanzo1 CjSAKSQ0mdQ3p/mVUVSOmzOOqszaQHXxfclviPRo7GCBAmHcdoGZhoxlEQaU8vjkjidC JWA048aq1fb0aq47KQ58KMM30zZ5KBhy6EsFxZzk0M2LfmX4jpgE6Ql0UflKmsqGB0qR Z9m3xzs0lYj8z/0uAiioNURmyO3StSqsmubWQ0qfIG9mfMR9plqhEZixLkCYodxZuzUN GB0dBemlcOud2MslvusZ4ZQYOnAkm0OQ8dplUsrUoKquub/JZFFSyNLdq6+HzrSlFfeF DNrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680557161; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kj5a1Gjv5u3ed9nScVQuCJw/TrKNl0CS2e9DPpgpMXA=; b=s/De2ImamZlo0AnQUPIvRjLFWCkjZZc8/8neH5K22FmePKkmVXPbdf4xHbC4AmyPxf WJiFgtgXq687K7HsmmYQkVuCPEL2gWplGPEAUZXF+YoMqiyddqp7Bo7+H2dgkcgr/Oql IAsqUCEqky5QaFrr3vswPruC9KQHHff1MvTKdSvhmIl+xvdeDkFjk9ioaOdN6jpSJOnO GbCbDAixh7jW4kR0PWdB3ge/Kxa/rrfDjoYz+kabRuP471yyRoh94KOkz/SG3Vs8CJMA yyECm7fIoq3egVQLkDK8CsSlJ0//FFrxd14Q+lGUUC9xx4xzprufg9q5Md/JjeO/3JvB CNXQ== X-Gm-Message-State: AAQBX9faX52xbGlG/iVAJNnEp/eVJzTyCdooKhmvym7i1UOjPZK/6bJI A1mwGoPISVdmt2U1GbGM47JskPOp0DCD38bCdfbKEQ== X-Received: by 2002:a4a:a406:0:b0:53e:944:8896 with SMTP id v6-20020a4aa406000000b0053e09448896mr354553ool.0.1680557160674; Mon, 03 Apr 2023 14:26:00 -0700 (PDT) MIME-Version: 1.0 References: <20230206172340.2639971-1-rananta@google.com> <20230206172340.2639971-7-rananta@google.com> In-Reply-To: From: Raghavendra Rao Ananta Date: Mon, 3 Apr 2023 14:25:49 -0700 Message-ID: Subject: Re: [PATCH v2 6/7] KVM: arm64: Break the table entries using TLBI range instructions To: Oliver Upton Cc: Oliver Upton , Marc Zyngier , Ricardo Koller , Reiji Watanabe , James Morse , Alexandru Elisei , Suzuki K Poulose , Will Deacon , Paolo Bonzini , Catalin Marinas , Jing Zhang , Colton Lewis , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 29, 2023 at 5:17=E2=80=AFPM Oliver Upton wrote: > > nit: s/break/invalidate/g > > There is a rather important degree of nuance there. 'Break' as it > relates to break-before-make implies that the PTE is made invalid and > visible to hardware _before_ a subsequent invalidation. There will be > systems that relax this requirement and also support TLBIRANGE. > > On Mon, Feb 06, 2023 at 05:23:39PM +0000, Raghavendra Rao Ananta wrote: > > Some nitpicking on the changelog: > > > Currently, when breaking up the stage-2 table entries, KVM > > 'breaking up stage-2 table entries' is rather ambiguous. Instead > describe the operation taking place on the page tables (i.e. hugepage > collapse). > > > would flush the entire VM's context using 'vmalls12e1is' > > TLBI operation. One of the problematic situation is collapsing > > table entries into a hugepage, specifically if the VM is > > faulting on many hugepages (say after dirty-logging). This > > creates a performance penality for the guest whose pages have > > typo: penalty > > > already been faulted earlier as they would have to refill their > > TLBs again. > > > > Hence, if the system supports it, use __kvm_tlb_flush_range_vmid_ipa() > > > to flush only the range of pages governed by the table entry, > > while leaving other TLB entries alone. An upcoming patch also > > takes advantage of this when breaking up table entries during > > the unmap operation. > > Language regarding an upcoming patch isn't necessary, as this one stands > on its own (implements and uses a range-based invalidation helper). > > > Signed-off-by: Raghavendra Rao Ananta > > --- > > arch/arm64/kvm/hyp/pgtable.c | 23 ++++++++++++++++++++--- > > 1 file changed, 20 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.= c > > index b11cf2c618a6c..0858d1fa85d6b 100644 > > --- a/arch/arm64/kvm/hyp/pgtable.c > > +++ b/arch/arm64/kvm/hyp/pgtable.c > > @@ -686,6 +686,20 @@ static bool stage2_try_set_pte(const struct kvm_pg= table_visit_ctx *ctx, kvm_pte_ > > return cmpxchg(ctx->ptep, ctx->old, new) =3D=3D ctx->old; > > } > > > > +static void kvm_pgtable_stage2_flush_range(struct kvm_s2_mmu *mmu, u64= start, u64 end, > > + u32 level, u32 tlb_level) > > +{ > > + if (system_supports_tlb_range()) > > You also check this in __kvm_tlb_flush_range(), ideally this should be > done exactly once per call. > > > + kvm_call_hyp(__kvm_tlb_flush_range_vmid_ipa, mmu, start, = end, level, tlb_level); > > + else > > + /* > > + * Invalidate the whole stage-2, as we may have numerous = leaf > > + * entries below us which would otherwise need invalidati= ng > > + * individually. > > + */ > > + kvm_call_hyp(__kvm_tlb_flush_vmid, mmu); > > +} > > + > > /** > > * stage2_try_break_pte() - Invalidates a pte according to the > > * 'break-before-make' requirements of the > > @@ -721,10 +735,13 @@ static bool stage2_try_break_pte(const struct kvm= _pgtable_visit_ctx *ctx, > > * Perform the appropriate TLB invalidation based on the evicted = pte > > * value (if any). > > */ > > - if (kvm_pte_table(ctx->old, ctx->level)) > > - kvm_call_hyp(__kvm_tlb_flush_vmid, mmu); > > - else if (kvm_pte_valid(ctx->old)) > > + if (kvm_pte_table(ctx->old, ctx->level)) { > > + u64 end =3D ctx->addr + kvm_granule_size(ctx->level); > > + > > + kvm_pgtable_stage2_flush_range(mmu, ctx->addr, end, ctx->= level, 0); > > + } else if (kvm_pte_valid(ctx->old)) { > > kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, mmu, ctx->addr, ct= x->level); > > + } > > > > if (stage2_pte_is_counted(ctx->old)) > > mm_ops->put_page(ctx->ptep); > > -- > > 2.39.1.519.gcb327c4b5f-goog > > > > ACK on all of the comments. I'll address them in next revision. Thank you. Raghavendra > > -- > Thanks, > Oliver