From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Date: Thu, 03 Aug 2023 00:28:12 +0100 Subject: [PATCH v7 12/12] KVM: arm64: Use TLBI range-based intructions for unmap In-Reply-To: References: <20230722022251.3446223-1-rananta@google.com> <20230722022251.3446223-13-rananta@google.com> <87jzulqz0v.wl-maz@kernel.org> Message-ID: <86fs5158j7.wl-maz@kernel.org> List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 31 Jul 2023 19:26:09 +0100, Raghavendra Rao Ananta wrote: > > On Thu, Jul 27, 2023 at 6:12?AM Marc Zyngier wrote: > > > > On Sat, 22 Jul 2023 03:22:51 +0100, > > Raghavendra Rao Ananta wrote: > > > > > > The current implementation of the stage-2 unmap walker traverses > > > the given range and, as a part of break-before-make, performs > > > TLB invalidations with a DSB for every PTE. A multitude of this > > > combination could cause a performance bottleneck on some systems. > > > > > > Hence, if the system supports FEAT_TLBIRANGE, defer the TLB > > > invalidations until the entire walk is finished, and then > > > use range-based instructions to invalidate the TLBs in one go. > > > Condition deferred TLB invalidation on the system supporting FWB, > > > as the optimization is entirely pointless when the unmap walker > > > needs to perform CMOs. > > > > > > Rename stage2_put_pte() to stage2_unmap_put_pte() as the function > > > now serves the stage-2 unmap walker specifically, rather than > > > acting generic. > > > > > > Signed-off-by: Raghavendra Rao Ananta > > > --- > > > arch/arm64/kvm/hyp/pgtable.c | 67 +++++++++++++++++++++++++++++++----- > > > 1 file changed, 58 insertions(+), 9 deletions(-) > > > > > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > > > index 5ef098af1736..cf88933a2ea0 100644 > > > --- a/arch/arm64/kvm/hyp/pgtable.c > > > +++ b/arch/arm64/kvm/hyp/pgtable.c > > > @@ -831,16 +831,54 @@ static void stage2_make_pte(const struct kvm_pgtable_visit_ctx *ctx, kvm_pte_t n > > > smp_store_release(ctx->ptep, new); > > > } > > > > > > -static void stage2_put_pte(const struct kvm_pgtable_visit_ctx *ctx, struct kvm_s2_mmu *mmu, > > > - struct kvm_pgtable_mm_ops *mm_ops) > > > +struct stage2_unmap_data { > > > + struct kvm_pgtable *pgt; > > > + bool defer_tlb_flush_init; > > > +}; > > > + > > > +static bool __stage2_unmap_defer_tlb_flush(struct kvm_pgtable *pgt) > > > +{ > > > + /* > > > + * If FEAT_TLBIRANGE is implemented, defer the individual > > > + * TLB invalidations until the entire walk is finished, and > > > + * then use the range-based TLBI instructions to do the > > > + * invalidations. Condition deferred TLB invalidation on the > > > + * system supporting FWB, as the optimization is entirely > > > + * pointless when the unmap walker needs to perform CMOs. > > > + */ > > > + return system_supports_tlb_range() && stage2_has_fwb(pgt); > > > +} > > > + > > > +static bool stage2_unmap_defer_tlb_flush(struct stage2_unmap_data *unmap_data) > > > +{ > > > + bool defer_tlb_flush = __stage2_unmap_defer_tlb_flush(unmap_data->pgt); > > > + > > > + /* > > > + * Since __stage2_unmap_defer_tlb_flush() is based on alternative > > > + * patching and the TLBIs' operations behavior depend on this, > > > + * track if there's any change in the state during the unmap sequence. > > > + */ > > > + WARN_ON(unmap_data->defer_tlb_flush_init != defer_tlb_flush); > > > + return defer_tlb_flush; > > > > I really don't understand what you're testing here. The ability to > > defer TLB invalidation is a function of the system capabilities > > (range+FWB) and a single flag that is only set on the host for pKVM. > > > > How could that change in the middle of the life of the system? if > > further begs the question about the need for the unmap_data data > > structure. > > > > It looks to me that we could simply pass the pgt pointer around and be > > done with it. Am I missing something obvious? > > > From one of the previous comments [1] (used in a different context), > I'm given to understand that since these feature checks are governed > by alternative patching, they can potentially change (at runtime?). Is > that not the case and I have misunderstood the idea in comment [1] > entirely? Is it solely used for optimization purposes and set only > once? Alternative patching, just like the static branches used to implement the capability stuff, is a one way street. At the point where KVM is initialised, these configurations are set in stone, and there is no going back. > If that's the case, I can get rid of the WARN_ON() and unmap_data. yes, please. Thanks, M. -- Without deviation from the norm, progress is not possible. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B185134B6 for ; Wed, 2 Aug 2023 23:28:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3031C433C7; Wed, 2 Aug 2023 23:28:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691018895; bh=nhWlDoBroZnLqL2p7qonO6/FNtiNV5czfDfLuSPQnQM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=k69LJczbkLd6JK8AoOtoqQZMCYBU6tHbpqBwWU0WMusxaXzNh2LMLKIRGA3YEJNCk HolTMn+Jr1nUMyv9P1fTFE+BDe41EbbHjYz1Tf2MnlqYi1vKwH+V33Vtq/gxibL9Ay STkoZZ37HTMwVV0WTmynxyAdZE8GXt2TOaBvGK8Aoyzm8SHjfD0H0THnOfKKj/LVyx 11fjb87SgX8bdXtX4/YsdVvfZ5Ran3A3/iSHNpthmsu1EnTLPYcvkB2YY7cH0WyNvs sGZYHgDSKMz8rN+P4QzAL2pVU0bdf9mzkU7dTfv6O4hpbg4ICVeaPypRq7fnbVpsIl meFdHsxGyRDHw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qRLGG-001VrN-Ot; Thu, 03 Aug 2023 00:28:12 +0100 Date: Thu, 03 Aug 2023 00:28:12 +0100 Message-ID: <86fs5158j7.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Oliver Upton , James Morse , Suzuki K Poulose , Paolo Bonzini , Sean Christopherson , Huacai Chen , Zenghui Yu , Anup Patel , Atish Patra , Jing Zhang , Reiji Watanabe , Colton Lewis , David Matlack , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 12/12] KVM: arm64: Use TLBI range-based intructions for unmap In-Reply-To: References: <20230722022251.3446223-1-rananta@google.com> <20230722022251.3446223-13-rananta@google.com> <87jzulqz0v.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rananta@google.com, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, pbonzini@redhat.com, seanjc@google.com, chenhuacai@kernel.org, yuzenghui@huawei.com, anup@brainfault.org, atishp@atishpatra.org, jingzhangos@google.com, reijiw@google.com, coltonlewis@google.com, dmatlack@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 31 Jul 2023 19:26:09 +0100, Raghavendra Rao Ananta wrote: >=20 > On Thu, Jul 27, 2023 at 6:12=E2=80=AFAM Marc Zyngier wro= te: > > > > On Sat, 22 Jul 2023 03:22:51 +0100, > > Raghavendra Rao Ananta wrote: > > > > > > The current implementation of the stage-2 unmap walker traverses > > > the given range and, as a part of break-before-make, performs > > > TLB invalidations with a DSB for every PTE. A multitude of this > > > combination could cause a performance bottleneck on some systems. > > > > > > Hence, if the system supports FEAT_TLBIRANGE, defer the TLB > > > invalidations until the entire walk is finished, and then > > > use range-based instructions to invalidate the TLBs in one go. > > > Condition deferred TLB invalidation on the system supporting FWB, > > > as the optimization is entirely pointless when the unmap walker > > > needs to perform CMOs. > > > > > > Rename stage2_put_pte() to stage2_unmap_put_pte() as the function > > > now serves the stage-2 unmap walker specifically, rather than > > > acting generic. > > > > > > Signed-off-by: Raghavendra Rao Ananta > > > --- > > > arch/arm64/kvm/hyp/pgtable.c | 67 +++++++++++++++++++++++++++++++---= -- > > > 1 file changed, 58 insertions(+), 9 deletions(-) > > > > > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtabl= e.c > > > index 5ef098af1736..cf88933a2ea0 100644 > > > --- a/arch/arm64/kvm/hyp/pgtable.c > > > +++ b/arch/arm64/kvm/hyp/pgtable.c > > > @@ -831,16 +831,54 @@ static void stage2_make_pte(const struct kvm_pg= table_visit_ctx *ctx, kvm_pte_t n > > > smp_store_release(ctx->ptep, new); > > > } > > > > > > -static void stage2_put_pte(const struct kvm_pgtable_visit_ctx *ctx, = struct kvm_s2_mmu *mmu, > > > - struct kvm_pgtable_mm_ops *mm_ops) > > > +struct stage2_unmap_data { > > > + struct kvm_pgtable *pgt; > > > + bool defer_tlb_flush_init; > > > +}; > > > + > > > +static bool __stage2_unmap_defer_tlb_flush(struct kvm_pgtable *pgt) > > > +{ > > > + /* > > > + * If FEAT_TLBIRANGE is implemented, defer the individual > > > + * TLB invalidations until the entire walk is finished, and > > > + * then use the range-based TLBI instructions to do the > > > + * invalidations. Condition deferred TLB invalidation on the > > > + * system supporting FWB, as the optimization is entirely > > > + * pointless when the unmap walker needs to perform CMOs. > > > + */ > > > + return system_supports_tlb_range() && stage2_has_fwb(pgt); > > > +} > > > + > > > +static bool stage2_unmap_defer_tlb_flush(struct stage2_unmap_data *u= nmap_data) > > > +{ > > > + bool defer_tlb_flush =3D __stage2_unmap_defer_tlb_flush(unmap_d= ata->pgt); > > > + > > > + /* > > > + * Since __stage2_unmap_defer_tlb_flush() is based on alternati= ve > > > + * patching and the TLBIs' operations behavior depend on this, > > > + * track if there's any change in the state during the unmap se= quence. > > > + */ > > > + WARN_ON(unmap_data->defer_tlb_flush_init !=3D defer_tlb_flush); > > > + return defer_tlb_flush; > > > > I really don't understand what you're testing here. The ability to > > defer TLB invalidation is a function of the system capabilities > > (range+FWB) and a single flag that is only set on the host for pKVM. > > > > How could that change in the middle of the life of the system? if > > further begs the question about the need for the unmap_data data > > structure. > > > > It looks to me that we could simply pass the pgt pointer around and be > > done with it. Am I missing something obvious? > > > From one of the previous comments [1] (used in a different context), > I'm given to understand that since these feature checks are governed > by alternative patching, they can potentially change (at runtime?). Is > that not the case and I have misunderstood the idea in comment [1] > entirely? Is it solely used for optimization purposes and set only > once? Alternative patching, just like the static branches used to implement the capability stuff, is a one way street. At the point where KVM is initialised, these configurations are set in stone, and there is no going back. > If that's the case, I can get rid of the WARN_ON() and unmap_data. yes, please. Thanks, M. --=20 Without deviation from the norm, progress is not possible. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BCA85C04A94 for ; Wed, 2 Aug 2023 23:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DP3tjmL7El4DgXFUy4UH/V14Y5aSYuqlhHnDqzoJ4f0=; b=JBFblnN9C6O4Vm /xl73YswBD04QVNbmbocQGn6ceesnQWuwJ3X42Iwmp2rmLNh02QJlADwlypSBz9/43qv7iLuvU6Qn RSNe3O7x9mlgEiahQBsaHUMTG1xLve1UXSJkgw3T9h4NW6PIHMl07kONHzB/BB8NpFCiJ2bLfacV2 +n72WzkaRh9LwLCDoA2FAaf1fmRvvc12vU68wxj0rKWuedpfUEA+id1UVA6+HF78fdcEAfGOAM848 hR8xEjmGBO+q9jkoPzOQMU7NrtswPf8Uic2W/aFbOCPheEQs4rESlm5J73LqYgN1nb2vSBcYW4gTI MhorZt0N21DgRV/KDeIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qRLGO-0067l2-0F; Wed, 02 Aug 2023 23:28:20 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qRLGK-0067ji-0K; Wed, 02 Aug 2023 23:28:17 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 878B661A55; Wed, 2 Aug 2023 23:28:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3031C433C7; Wed, 2 Aug 2023 23:28:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691018895; bh=nhWlDoBroZnLqL2p7qonO6/FNtiNV5czfDfLuSPQnQM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=k69LJczbkLd6JK8AoOtoqQZMCYBU6tHbpqBwWU0WMusxaXzNh2LMLKIRGA3YEJNCk HolTMn+Jr1nUMyv9P1fTFE+BDe41EbbHjYz1Tf2MnlqYi1vKwH+V33Vtq/gxibL9Ay STkoZZ37HTMwVV0WTmynxyAdZE8GXt2TOaBvGK8Aoyzm8SHjfD0H0THnOfKKj/LVyx 11fjb87SgX8bdXtX4/YsdVvfZ5Ran3A3/iSHNpthmsu1EnTLPYcvkB2YY7cH0WyNvs sGZYHgDSKMz8rN+P4QzAL2pVU0bdf9mzkU7dTfv6O4hpbg4ICVeaPypRq7fnbVpsIl meFdHsxGyRDHw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qRLGG-001VrN-Ot; Thu, 03 Aug 2023 00:28:12 +0100 Date: Thu, 03 Aug 2023 00:28:12 +0100 Message-ID: <86fs5158j7.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Oliver Upton , James Morse , Suzuki K Poulose , Paolo Bonzini , Sean Christopherson , Huacai Chen , Zenghui Yu , Anup Patel , Atish Patra , Jing Zhang , Reiji Watanabe , Colton Lewis , David Matlack , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 12/12] KVM: arm64: Use TLBI range-based intructions for unmap In-Reply-To: References: <20230722022251.3446223-1-rananta@google.com> <20230722022251.3446223-13-rananta@google.com> <87jzulqz0v.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rananta@google.com, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, pbonzini@redhat.com, seanjc@google.com, chenhuacai@kernel.org, yuzenghui@huawei.com, anup@brainfault.org, atishp@atishpatra.org, jingzhangos@google.com, reijiw@google.com, coltonlewis@google.com, dmatlack@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230802_162816_233626_A3BFDF24 X-CRM114-Status: GOOD ( 43.27 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gTW9uLCAzMSBKdWwgMjAyMyAxOToyNjowOSArMDEwMCwKUmFnaGF2ZW5kcmEgUmFvIEFuYW50 YSA8cmFuYW50YUBnb29nbGUuY29tPiB3cm90ZToKPiAKPiBPbiBUaHUsIEp1bCAyNywgMjAyMyBh dCA2OjEy4oCvQU0gTWFyYyBaeW5naWVyIDxtYXpAa2VybmVsLm9yZz4gd3JvdGU6Cj4gPgo+ID4g T24gU2F0LCAyMiBKdWwgMjAyMyAwMzoyMjo1MSArMDEwMCwKPiA+IFJhZ2hhdmVuZHJhIFJhbyBB bmFudGEgPHJhbmFudGFAZ29vZ2xlLmNvbT4gd3JvdGU6Cj4gPiA+Cj4gPiA+IFRoZSBjdXJyZW50 IGltcGxlbWVudGF0aW9uIG9mIHRoZSBzdGFnZS0yIHVubWFwIHdhbGtlciB0cmF2ZXJzZXMKPiA+ ID4gdGhlIGdpdmVuIHJhbmdlIGFuZCwgYXMgYSBwYXJ0IG9mIGJyZWFrLWJlZm9yZS1tYWtlLCBw ZXJmb3Jtcwo+ID4gPiBUTEIgaW52YWxpZGF0aW9ucyB3aXRoIGEgRFNCIGZvciBldmVyeSBQVEUu IEEgbXVsdGl0dWRlIG9mIHRoaXMKPiA+ID4gY29tYmluYXRpb24gY291bGQgY2F1c2UgYSBwZXJm b3JtYW5jZSBib3R0bGVuZWNrIG9uIHNvbWUgc3lzdGVtcy4KPiA+ID4KPiA+ID4gSGVuY2UsIGlm IHRoZSBzeXN0ZW0gc3VwcG9ydHMgRkVBVF9UTEJJUkFOR0UsIGRlZmVyIHRoZSBUTEIKPiA+ID4g aW52YWxpZGF0aW9ucyB1bnRpbCB0aGUgZW50aXJlIHdhbGsgaXMgZmluaXNoZWQsIGFuZCB0aGVu Cj4gPiA+IHVzZSByYW5nZS1iYXNlZCBpbnN0cnVjdGlvbnMgdG8gaW52YWxpZGF0ZSB0aGUgVExC cyBpbiBvbmUgZ28uCj4gPiA+IENvbmRpdGlvbiBkZWZlcnJlZCBUTEIgaW52YWxpZGF0aW9uIG9u IHRoZSBzeXN0ZW0gc3VwcG9ydGluZyBGV0IsCj4gPiA+IGFzIHRoZSBvcHRpbWl6YXRpb24gaXMg ZW50aXJlbHkgcG9pbnRsZXNzIHdoZW4gdGhlIHVubWFwIHdhbGtlcgo+ID4gPiBuZWVkcyB0byBw ZXJmb3JtIENNT3MuCj4gPiA+Cj4gPiA+IFJlbmFtZSBzdGFnZTJfcHV0X3B0ZSgpIHRvIHN0YWdl Ml91bm1hcF9wdXRfcHRlKCkgYXMgdGhlIGZ1bmN0aW9uCj4gPiA+IG5vdyBzZXJ2ZXMgdGhlIHN0 YWdlLTIgdW5tYXAgd2Fsa2VyIHNwZWNpZmljYWxseSwgcmF0aGVyIHRoYW4KPiA+ID4gYWN0aW5n IGdlbmVyaWMuCj4gPiA+Cj4gPiA+IFNpZ25lZC1vZmYtYnk6IFJhZ2hhdmVuZHJhIFJhbyBBbmFu dGEgPHJhbmFudGFAZ29vZ2xlLmNvbT4KPiA+ID4gLS0tCj4gPiA+ICBhcmNoL2FybTY0L2t2bS9o eXAvcGd0YWJsZS5jIHwgNjcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tCj4g PiA+ICAxIGZpbGUgY2hhbmdlZCwgNTggaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkKPiA+ ID4KPiA+ID4gZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQva3ZtL2h5cC9wZ3RhYmxlLmMgYi9hcmNo L2FybTY0L2t2bS9oeXAvcGd0YWJsZS5jCj4gPiA+IGluZGV4IDVlZjA5OGFmMTczNi4uY2Y4ODkz M2EyZWEwIDEwMDY0NAo+ID4gPiAtLS0gYS9hcmNoL2FybTY0L2t2bS9oeXAvcGd0YWJsZS5jCj4g PiA+ICsrKyBiL2FyY2gvYXJtNjQva3ZtL2h5cC9wZ3RhYmxlLmMKPiA+ID4gQEAgLTgzMSwxNiAr ODMxLDU0IEBAIHN0YXRpYyB2b2lkIHN0YWdlMl9tYWtlX3B0ZShjb25zdCBzdHJ1Y3Qga3ZtX3Bn dGFibGVfdmlzaXRfY3R4ICpjdHgsIGt2bV9wdGVfdCBuCj4gPiA+ICAgICAgIHNtcF9zdG9yZV9y ZWxlYXNlKGN0eC0+cHRlcCwgbmV3KTsKPiA+ID4gIH0KPiA+ID4KPiA+ID4gLXN0YXRpYyB2b2lk IHN0YWdlMl9wdXRfcHRlKGNvbnN0IHN0cnVjdCBrdm1fcGd0YWJsZV92aXNpdF9jdHggKmN0eCwg c3RydWN0IGt2bV9zMl9tbXUgKm1tdSwKPiA+ID4gLSAgICAgICAgICAgICAgICAgICAgICAgIHN0 cnVjdCBrdm1fcGd0YWJsZV9tbV9vcHMgKm1tX29wcykKPiA+ID4gK3N0cnVjdCBzdGFnZTJfdW5t YXBfZGF0YSB7Cj4gPiA+ICsgICAgIHN0cnVjdCBrdm1fcGd0YWJsZSAqcGd0Owo+ID4gPiArICAg ICBib29sIGRlZmVyX3RsYl9mbHVzaF9pbml0Owo+ID4gPiArfTsKPiA+ID4gKwo+ID4gPiArc3Rh dGljIGJvb2wgX19zdGFnZTJfdW5tYXBfZGVmZXJfdGxiX2ZsdXNoKHN0cnVjdCBrdm1fcGd0YWJs ZSAqcGd0KQo+ID4gPiArewo+ID4gPiArICAgICAvKgo+ID4gPiArICAgICAgKiBJZiBGRUFUX1RM QklSQU5HRSBpcyBpbXBsZW1lbnRlZCwgZGVmZXIgdGhlIGluZGl2aWR1YWwKPiA+ID4gKyAgICAg ICogVExCIGludmFsaWRhdGlvbnMgdW50aWwgdGhlIGVudGlyZSB3YWxrIGlzIGZpbmlzaGVkLCBh bmQKPiA+ID4gKyAgICAgICogdGhlbiB1c2UgdGhlIHJhbmdlLWJhc2VkIFRMQkkgaW5zdHJ1Y3Rp b25zIHRvIGRvIHRoZQo+ID4gPiArICAgICAgKiBpbnZhbGlkYXRpb25zLiBDb25kaXRpb24gZGVm ZXJyZWQgVExCIGludmFsaWRhdGlvbiBvbiB0aGUKPiA+ID4gKyAgICAgICogc3lzdGVtIHN1cHBv cnRpbmcgRldCLCBhcyB0aGUgb3B0aW1pemF0aW9uIGlzIGVudGlyZWx5Cj4gPiA+ICsgICAgICAq IHBvaW50bGVzcyB3aGVuIHRoZSB1bm1hcCB3YWxrZXIgbmVlZHMgdG8gcGVyZm9ybSBDTU9zLgo+ ID4gPiArICAgICAgKi8KPiA+ID4gKyAgICAgcmV0dXJuIHN5c3RlbV9zdXBwb3J0c190bGJfcmFu Z2UoKSAmJiBzdGFnZTJfaGFzX2Z3YihwZ3QpOwo+ID4gPiArfQo+ID4gPiArCj4gPiA+ICtzdGF0 aWMgYm9vbCBzdGFnZTJfdW5tYXBfZGVmZXJfdGxiX2ZsdXNoKHN0cnVjdCBzdGFnZTJfdW5tYXBf ZGF0YSAqdW5tYXBfZGF0YSkKPiA+ID4gK3sKPiA+ID4gKyAgICAgYm9vbCBkZWZlcl90bGJfZmx1 c2ggPSBfX3N0YWdlMl91bm1hcF9kZWZlcl90bGJfZmx1c2godW5tYXBfZGF0YS0+cGd0KTsKPiA+ ID4gKwo+ID4gPiArICAgICAvKgo+ID4gPiArICAgICAgKiBTaW5jZSBfX3N0YWdlMl91bm1hcF9k ZWZlcl90bGJfZmx1c2goKSBpcyBiYXNlZCBvbiBhbHRlcm5hdGl2ZQo+ID4gPiArICAgICAgKiBw YXRjaGluZyBhbmQgdGhlIFRMQklzJyBvcGVyYXRpb25zIGJlaGF2aW9yIGRlcGVuZCBvbiB0aGlz LAo+ID4gPiArICAgICAgKiB0cmFjayBpZiB0aGVyZSdzIGFueSBjaGFuZ2UgaW4gdGhlIHN0YXRl IGR1cmluZyB0aGUgdW5tYXAgc2VxdWVuY2UuCj4gPiA+ICsgICAgICAqLwo+ID4gPiArICAgICBX QVJOX09OKHVubWFwX2RhdGEtPmRlZmVyX3RsYl9mbHVzaF9pbml0ICE9IGRlZmVyX3RsYl9mbHVz aCk7Cj4gPiA+ICsgICAgIHJldHVybiBkZWZlcl90bGJfZmx1c2g7Cj4gPgo+ID4gSSByZWFsbHkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSdyZSB0ZXN0aW5nIGhlcmUuIFRoZSBhYmlsaXR5IHRv Cj4gPiBkZWZlciBUTEIgaW52YWxpZGF0aW9uIGlzIGEgZnVuY3Rpb24gb2YgdGhlIHN5c3RlbSBj YXBhYmlsaXRpZXMKPiA+IChyYW5nZStGV0IpIGFuZCBhIHNpbmdsZSBmbGFnIHRoYXQgaXMgb25s eSBzZXQgb24gdGhlIGhvc3QgZm9yIHBLVk0uCj4gPgo+ID4gSG93IGNvdWxkIHRoYXQgY2hhbmdl IGluIHRoZSBtaWRkbGUgb2YgdGhlIGxpZmUgb2YgdGhlIHN5c3RlbT8gaWYKPiA+IGZ1cnRoZXIg YmVncyB0aGUgcXVlc3Rpb24gYWJvdXQgdGhlIG5lZWQgZm9yIHRoZSB1bm1hcF9kYXRhIGRhdGEK PiA+IHN0cnVjdHVyZS4KPiA+Cj4gPiBJdCBsb29rcyB0byBtZSB0aGF0IHdlIGNvdWxkIHNpbXBs eSBwYXNzIHRoZSBwZ3QgcG9pbnRlciBhcm91bmQgYW5kIGJlCj4gPiBkb25lIHdpdGggaXQuIEFt IEkgbWlzc2luZyBzb21ldGhpbmcgb2J2aW91cz8KPiA+Cj4gRnJvbSBvbmUgb2YgdGhlIHByZXZp b3VzIGNvbW1lbnRzIFsxXSAodXNlZCBpbiBhIGRpZmZlcmVudCBjb250ZXh0KSwKPiBJJ20gZ2l2 ZW4gdG8gdW5kZXJzdGFuZCB0aGF0IHNpbmNlIHRoZXNlIGZlYXR1cmUgY2hlY2tzIGFyZSBnb3Zl cm5lZAo+IGJ5IGFsdGVybmF0aXZlIHBhdGNoaW5nLCB0aGV5IGNhbiBwb3RlbnRpYWxseSBjaGFu Z2UgKGF0IHJ1bnRpbWU/KS4gSXMKPiB0aGF0IG5vdCB0aGUgY2FzZSBhbmQgSSBoYXZlIG1pc3Vu ZGVyc3Rvb2QgdGhlIGlkZWEgaW4gY29tbWVudCBbMV0KPiBlbnRpcmVseT8gSXMgaXQgc29sZWx5 IHVzZWQgZm9yIG9wdGltaXphdGlvbiBwdXJwb3NlcyBhbmQgc2V0IG9ubHkKPiBvbmNlPwoKQWx0 ZXJuYXRpdmUgcGF0Y2hpbmcsIGp1c3QgbGlrZSB0aGUgc3RhdGljIGJyYW5jaGVzIHVzZWQgdG8g aW1wbGVtZW50CnRoZSBjYXBhYmlsaXR5IHN0dWZmLCBpcyBhIG9uZSB3YXkgc3RyZWV0LiBBdCB0 aGUgcG9pbnQgd2hlcmUgS1ZNIGlzCmluaXRpYWxpc2VkLCB0aGVzZSBjb25maWd1cmF0aW9ucyBh cmUgc2V0IGluIHN0b25lLCBhbmQgdGhlcmUgaXMgbm8KZ29pbmcgYmFjay4KCj4gSWYgdGhhdCdz IHRoZSBjYXNlLCBJIGNhbiBnZXQgcmlkIG9mIHRoZSBXQVJOX09OKCkgYW5kIHVubWFwX2RhdGEu Cgp5ZXMsIHBsZWFzZS4KClRoYW5rcywKCglNLgoKLS0gCldpdGhvdXQgZGV2aWF0aW9uIGZyb20g dGhlIG5vcm0sIHByb2dyZXNzIGlzIG5vdCBwb3NzaWJsZS4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdApsaW51 eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21h aWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6A4E2C001DE for ; Wed, 2 Aug 2023 23:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0Iyq+BrpkTcXKwE7Wf9lfMGAgJvi7C6cxSw5fFUtI9k=; b=oA2PRNlihfvO5J vqBTWPOamJPNy63KR36waMriyX7nYDv8Xx+nl0MQ0THAGdkc1W14E0sjMe6QXovdtUc6mg39LJKQy dOYT+IPeJhsa+ZEEWt2uyzy7Llk+euloXHTMCvFVtIO5fLer5k27xT3lI5xTOJfr/bIFjzzgTFB6d 48kekBzE2a0ED2mRSdZouXFsUFzmepBrfHN9bVTKLdoRlk8ko7RwIEGl5DBryjCM/IgoTGnrOJhyY OTTvm0XE4ZG1pd5SwY+ICcxkeaEIi7bZgTc8YkMsPKo8eI0pcCPmxD7T1ltwIB6qxSuXolnjS5qiw 8bMHzZx8jevf7BLsyhGg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qRLGN-0067kk-1t; Wed, 02 Aug 2023 23:28:19 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qRLGK-0067ji-0K; Wed, 02 Aug 2023 23:28:17 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 878B661A55; Wed, 2 Aug 2023 23:28:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3031C433C7; Wed, 2 Aug 2023 23:28:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691018895; bh=nhWlDoBroZnLqL2p7qonO6/FNtiNV5czfDfLuSPQnQM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=k69LJczbkLd6JK8AoOtoqQZMCYBU6tHbpqBwWU0WMusxaXzNh2LMLKIRGA3YEJNCk HolTMn+Jr1nUMyv9P1fTFE+BDe41EbbHjYz1Tf2MnlqYi1vKwH+V33Vtq/gxibL9Ay STkoZZ37HTMwVV0WTmynxyAdZE8GXt2TOaBvGK8Aoyzm8SHjfD0H0THnOfKKj/LVyx 11fjb87SgX8bdXtX4/YsdVvfZ5Ran3A3/iSHNpthmsu1EnTLPYcvkB2YY7cH0WyNvs sGZYHgDSKMz8rN+P4QzAL2pVU0bdf9mzkU7dTfv6O4hpbg4ICVeaPypRq7fnbVpsIl meFdHsxGyRDHw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qRLGG-001VrN-Ot; Thu, 03 Aug 2023 00:28:12 +0100 Date: Thu, 03 Aug 2023 00:28:12 +0100 Message-ID: <86fs5158j7.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Oliver Upton , James Morse , Suzuki K Poulose , Paolo Bonzini , Sean Christopherson , Huacai Chen , Zenghui Yu , Anup Patel , Atish Patra , Jing Zhang , Reiji Watanabe , Colton Lewis , David Matlack , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 12/12] KVM: arm64: Use TLBI range-based intructions for unmap In-Reply-To: References: <20230722022251.3446223-1-rananta@google.com> <20230722022251.3446223-13-rananta@google.com> <87jzulqz0v.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rananta@google.com, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, pbonzini@redhat.com, seanjc@google.com, chenhuacai@kernel.org, yuzenghui@huawei.com, anup@brainfault.org, atishp@atishpatra.org, jingzhangos@google.com, reijiw@google.com, coltonlewis@google.com, dmatlack@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230802_162816_233626_A3BFDF24 X-CRM114-Status: GOOD ( 43.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gTW9uLCAzMSBKdWwgMjAyMyAxOToyNjowOSArMDEwMCwKUmFnaGF2ZW5kcmEgUmFvIEFuYW50 YSA8cmFuYW50YUBnb29nbGUuY29tPiB3cm90ZToKPiAKPiBPbiBUaHUsIEp1bCAyNywgMjAyMyBh dCA2OjEy4oCvQU0gTWFyYyBaeW5naWVyIDxtYXpAa2VybmVsLm9yZz4gd3JvdGU6Cj4gPgo+ID4g T24gU2F0LCAyMiBKdWwgMjAyMyAwMzoyMjo1MSArMDEwMCwKPiA+IFJhZ2hhdmVuZHJhIFJhbyBB bmFudGEgPHJhbmFudGFAZ29vZ2xlLmNvbT4gd3JvdGU6Cj4gPiA+Cj4gPiA+IFRoZSBjdXJyZW50 IGltcGxlbWVudGF0aW9uIG9mIHRoZSBzdGFnZS0yIHVubWFwIHdhbGtlciB0cmF2ZXJzZXMKPiA+ ID4gdGhlIGdpdmVuIHJhbmdlIGFuZCwgYXMgYSBwYXJ0IG9mIGJyZWFrLWJlZm9yZS1tYWtlLCBw ZXJmb3Jtcwo+ID4gPiBUTEIgaW52YWxpZGF0aW9ucyB3aXRoIGEgRFNCIGZvciBldmVyeSBQVEUu IEEgbXVsdGl0dWRlIG9mIHRoaXMKPiA+ID4gY29tYmluYXRpb24gY291bGQgY2F1c2UgYSBwZXJm b3JtYW5jZSBib3R0bGVuZWNrIG9uIHNvbWUgc3lzdGVtcy4KPiA+ID4KPiA+ID4gSGVuY2UsIGlm IHRoZSBzeXN0ZW0gc3VwcG9ydHMgRkVBVF9UTEJJUkFOR0UsIGRlZmVyIHRoZSBUTEIKPiA+ID4g aW52YWxpZGF0aW9ucyB1bnRpbCB0aGUgZW50aXJlIHdhbGsgaXMgZmluaXNoZWQsIGFuZCB0aGVu Cj4gPiA+IHVzZSByYW5nZS1iYXNlZCBpbnN0cnVjdGlvbnMgdG8gaW52YWxpZGF0ZSB0aGUgVExC cyBpbiBvbmUgZ28uCj4gPiA+IENvbmRpdGlvbiBkZWZlcnJlZCBUTEIgaW52YWxpZGF0aW9uIG9u IHRoZSBzeXN0ZW0gc3VwcG9ydGluZyBGV0IsCj4gPiA+IGFzIHRoZSBvcHRpbWl6YXRpb24gaXMg ZW50aXJlbHkgcG9pbnRsZXNzIHdoZW4gdGhlIHVubWFwIHdhbGtlcgo+ID4gPiBuZWVkcyB0byBw ZXJmb3JtIENNT3MuCj4gPiA+Cj4gPiA+IFJlbmFtZSBzdGFnZTJfcHV0X3B0ZSgpIHRvIHN0YWdl Ml91bm1hcF9wdXRfcHRlKCkgYXMgdGhlIGZ1bmN0aW9uCj4gPiA+IG5vdyBzZXJ2ZXMgdGhlIHN0 YWdlLTIgdW5tYXAgd2Fsa2VyIHNwZWNpZmljYWxseSwgcmF0aGVyIHRoYW4KPiA+ID4gYWN0aW5n IGdlbmVyaWMuCj4gPiA+Cj4gPiA+IFNpZ25lZC1vZmYtYnk6IFJhZ2hhdmVuZHJhIFJhbyBBbmFu dGEgPHJhbmFudGFAZ29vZ2xlLmNvbT4KPiA+ID4gLS0tCj4gPiA+ICBhcmNoL2FybTY0L2t2bS9o eXAvcGd0YWJsZS5jIHwgNjcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tCj4g PiA+ICAxIGZpbGUgY2hhbmdlZCwgNTggaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkKPiA+ ID4KPiA+ID4gZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQva3ZtL2h5cC9wZ3RhYmxlLmMgYi9hcmNo L2FybTY0L2t2bS9oeXAvcGd0YWJsZS5jCj4gPiA+IGluZGV4IDVlZjA5OGFmMTczNi4uY2Y4ODkz M2EyZWEwIDEwMDY0NAo+ID4gPiAtLS0gYS9hcmNoL2FybTY0L2t2bS9oeXAvcGd0YWJsZS5jCj4g PiA+ICsrKyBiL2FyY2gvYXJtNjQva3ZtL2h5cC9wZ3RhYmxlLmMKPiA+ID4gQEAgLTgzMSwxNiAr ODMxLDU0IEBAIHN0YXRpYyB2b2lkIHN0YWdlMl9tYWtlX3B0ZShjb25zdCBzdHJ1Y3Qga3ZtX3Bn dGFibGVfdmlzaXRfY3R4ICpjdHgsIGt2bV9wdGVfdCBuCj4gPiA+ICAgICAgIHNtcF9zdG9yZV9y ZWxlYXNlKGN0eC0+cHRlcCwgbmV3KTsKPiA+ID4gIH0KPiA+ID4KPiA+ID4gLXN0YXRpYyB2b2lk IHN0YWdlMl9wdXRfcHRlKGNvbnN0IHN0cnVjdCBrdm1fcGd0YWJsZV92aXNpdF9jdHggKmN0eCwg c3RydWN0IGt2bV9zMl9tbXUgKm1tdSwKPiA+ID4gLSAgICAgICAgICAgICAgICAgICAgICAgIHN0 cnVjdCBrdm1fcGd0YWJsZV9tbV9vcHMgKm1tX29wcykKPiA+ID4gK3N0cnVjdCBzdGFnZTJfdW5t YXBfZGF0YSB7Cj4gPiA+ICsgICAgIHN0cnVjdCBrdm1fcGd0YWJsZSAqcGd0Owo+ID4gPiArICAg ICBib29sIGRlZmVyX3RsYl9mbHVzaF9pbml0Owo+ID4gPiArfTsKPiA+ID4gKwo+ID4gPiArc3Rh dGljIGJvb2wgX19zdGFnZTJfdW5tYXBfZGVmZXJfdGxiX2ZsdXNoKHN0cnVjdCBrdm1fcGd0YWJs ZSAqcGd0KQo+ID4gPiArewo+ID4gPiArICAgICAvKgo+ID4gPiArICAgICAgKiBJZiBGRUFUX1RM QklSQU5HRSBpcyBpbXBsZW1lbnRlZCwgZGVmZXIgdGhlIGluZGl2aWR1YWwKPiA+ID4gKyAgICAg ICogVExCIGludmFsaWRhdGlvbnMgdW50aWwgdGhlIGVudGlyZSB3YWxrIGlzIGZpbmlzaGVkLCBh bmQKPiA+ID4gKyAgICAgICogdGhlbiB1c2UgdGhlIHJhbmdlLWJhc2VkIFRMQkkgaW5zdHJ1Y3Rp b25zIHRvIGRvIHRoZQo+ID4gPiArICAgICAgKiBpbnZhbGlkYXRpb25zLiBDb25kaXRpb24gZGVm ZXJyZWQgVExCIGludmFsaWRhdGlvbiBvbiB0aGUKPiA+ID4gKyAgICAgICogc3lzdGVtIHN1cHBv cnRpbmcgRldCLCBhcyB0aGUgb3B0aW1pemF0aW9uIGlzIGVudGlyZWx5Cj4gPiA+ICsgICAgICAq IHBvaW50bGVzcyB3aGVuIHRoZSB1bm1hcCB3YWxrZXIgbmVlZHMgdG8gcGVyZm9ybSBDTU9zLgo+ ID4gPiArICAgICAgKi8KPiA+ID4gKyAgICAgcmV0dXJuIHN5c3RlbV9zdXBwb3J0c190bGJfcmFu Z2UoKSAmJiBzdGFnZTJfaGFzX2Z3YihwZ3QpOwo+ID4gPiArfQo+ID4gPiArCj4gPiA+ICtzdGF0 aWMgYm9vbCBzdGFnZTJfdW5tYXBfZGVmZXJfdGxiX2ZsdXNoKHN0cnVjdCBzdGFnZTJfdW5tYXBf ZGF0YSAqdW5tYXBfZGF0YSkKPiA+ID4gK3sKPiA+ID4gKyAgICAgYm9vbCBkZWZlcl90bGJfZmx1 c2ggPSBfX3N0YWdlMl91bm1hcF9kZWZlcl90bGJfZmx1c2godW5tYXBfZGF0YS0+cGd0KTsKPiA+ ID4gKwo+ID4gPiArICAgICAvKgo+ID4gPiArICAgICAgKiBTaW5jZSBfX3N0YWdlMl91bm1hcF9k ZWZlcl90bGJfZmx1c2goKSBpcyBiYXNlZCBvbiBhbHRlcm5hdGl2ZQo+ID4gPiArICAgICAgKiBw YXRjaGluZyBhbmQgdGhlIFRMQklzJyBvcGVyYXRpb25zIGJlaGF2aW9yIGRlcGVuZCBvbiB0aGlz LAo+ID4gPiArICAgICAgKiB0cmFjayBpZiB0aGVyZSdzIGFueSBjaGFuZ2UgaW4gdGhlIHN0YXRl IGR1cmluZyB0aGUgdW5tYXAgc2VxdWVuY2UuCj4gPiA+ICsgICAgICAqLwo+ID4gPiArICAgICBX QVJOX09OKHVubWFwX2RhdGEtPmRlZmVyX3RsYl9mbHVzaF9pbml0ICE9IGRlZmVyX3RsYl9mbHVz aCk7Cj4gPiA+ICsgICAgIHJldHVybiBkZWZlcl90bGJfZmx1c2g7Cj4gPgo+ID4gSSByZWFsbHkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSdyZSB0ZXN0aW5nIGhlcmUuIFRoZSBhYmlsaXR5IHRv Cj4gPiBkZWZlciBUTEIgaW52YWxpZGF0aW9uIGlzIGEgZnVuY3Rpb24gb2YgdGhlIHN5c3RlbSBj YXBhYmlsaXRpZXMKPiA+IChyYW5nZStGV0IpIGFuZCBhIHNpbmdsZSBmbGFnIHRoYXQgaXMgb25s eSBzZXQgb24gdGhlIGhvc3QgZm9yIHBLVk0uCj4gPgo+ID4gSG93IGNvdWxkIHRoYXQgY2hhbmdl IGluIHRoZSBtaWRkbGUgb2YgdGhlIGxpZmUgb2YgdGhlIHN5c3RlbT8gaWYKPiA+IGZ1cnRoZXIg YmVncyB0aGUgcXVlc3Rpb24gYWJvdXQgdGhlIG5lZWQgZm9yIHRoZSB1bm1hcF9kYXRhIGRhdGEK PiA+IHN0cnVjdHVyZS4KPiA+Cj4gPiBJdCBsb29rcyB0byBtZSB0aGF0IHdlIGNvdWxkIHNpbXBs eSBwYXNzIHRoZSBwZ3QgcG9pbnRlciBhcm91bmQgYW5kIGJlCj4gPiBkb25lIHdpdGggaXQuIEFt IEkgbWlzc2luZyBzb21ldGhpbmcgb2J2aW91cz8KPiA+Cj4gRnJvbSBvbmUgb2YgdGhlIHByZXZp b3VzIGNvbW1lbnRzIFsxXSAodXNlZCBpbiBhIGRpZmZlcmVudCBjb250ZXh0KSwKPiBJJ20gZ2l2 ZW4gdG8gdW5kZXJzdGFuZCB0aGF0IHNpbmNlIHRoZXNlIGZlYXR1cmUgY2hlY2tzIGFyZSBnb3Zl cm5lZAo+IGJ5IGFsdGVybmF0aXZlIHBhdGNoaW5nLCB0aGV5IGNhbiBwb3RlbnRpYWxseSBjaGFu Z2UgKGF0IHJ1bnRpbWU/KS4gSXMKPiB0aGF0IG5vdCB0aGUgY2FzZSBhbmQgSSBoYXZlIG1pc3Vu ZGVyc3Rvb2QgdGhlIGlkZWEgaW4gY29tbWVudCBbMV0KPiBlbnRpcmVseT8gSXMgaXQgc29sZWx5 IHVzZWQgZm9yIG9wdGltaXphdGlvbiBwdXJwb3NlcyBhbmQgc2V0IG9ubHkKPiBvbmNlPwoKQWx0 ZXJuYXRpdmUgcGF0Y2hpbmcsIGp1c3QgbGlrZSB0aGUgc3RhdGljIGJyYW5jaGVzIHVzZWQgdG8g aW1wbGVtZW50CnRoZSBjYXBhYmlsaXR5IHN0dWZmLCBpcyBhIG9uZSB3YXkgc3RyZWV0LiBBdCB0 aGUgcG9pbnQgd2hlcmUgS1ZNIGlzCmluaXRpYWxpc2VkLCB0aGVzZSBjb25maWd1cmF0aW9ucyBh cmUgc2V0IGluIHN0b25lLCBhbmQgdGhlcmUgaXMgbm8KZ29pbmcgYmFjay4KCj4gSWYgdGhhdCdz IHRoZSBjYXNlLCBJIGNhbiBnZXQgcmlkIG9mIHRoZSBXQVJOX09OKCkgYW5kIHVubWFwX2RhdGEu Cgp5ZXMsIHBsZWFzZS4KClRoYW5rcywKCglNLgoKLS0gCldpdGhvdXQgZGV2aWF0aW9uIGZyb20g dGhlIG5vcm0sIHByb2dyZXNzIGlzIG5vdCBwb3NzaWJsZS4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0 CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFk ZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK