linux-kernel - Re: [PATCH v3 7/7] KVM: arm64: Use TLBI range-based intructions for unmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZF5xLrr2tEYdLL1i@linux.dev>
Date:   Fri, 12 May 2023 17:02:38 +0000
From:   Oliver Upton <oliver.upton@...ux.dev>
To:     Raghavendra Rao Ananta <rananta@...gle.com>
Cc:     Marc Zyngier <maz@...nel.org>, James Morse <james.morse@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Ricardo Koller <ricarkol@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jing Zhang <jingzhangos@...gle.com>,
        Colton Lewis <coltonlewis@...gle.com>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v3 7/7] KVM: arm64: Use TLBI range-based intructions for
 unmap

Hi Raghavendra,

On Fri, Apr 14, 2023 at 05:29:22PM +0000, 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.
> 
> 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 this upon S2FWB in order to avoid walking the page-table
> again to perform the CMOs after issuing the TLBI.
> 
> Signed-off-by: Raghavendra Rao Ananta <rananta@...gle.com>
> Suggested-by: Oliver Upton <oliver.upton@...ux.dev>
> ---
>  arch/arm64/kvm/hyp/pgtable.c | 33 +++++++++++++++++++++++++++++----
>  1 file changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 3f136e35feb5e..bcb748e3566c7 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -987,10 +987,16 @@ int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
>  	return ret;
>  }
>  
> +struct stage2_unmap_data {
> +	struct kvm_pgtable *pgt;
> +	bool skip_pte_tlbis;
> +};
> +
>  static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
>  			       enum kvm_pgtable_walk_flags visit)
>  {
> -	struct kvm_pgtable *pgt = ctx->arg;
> +	struct stage2_unmap_data *unmap_data = ctx->arg;
> +	struct kvm_pgtable *pgt = unmap_data->pgt;
>  	struct kvm_s2_mmu *mmu = pgt->mmu;
>  	struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
>  	kvm_pte_t *childp = NULL;
> @@ -1018,7 +1024,7 @@ static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
>  	 * block entry and rely on the remaining portions being faulted
>  	 * back lazily.
>  	 */
> -	stage2_put_pte(ctx, mmu, mm_ops, false);
> +	stage2_put_pte(ctx, mmu, mm_ops, unmap_data->skip_pte_tlbis);
>  
>  	if (need_flush && mm_ops->dcache_clean_inval_poc)
>  		mm_ops->dcache_clean_inval_poc(kvm_pte_follow(ctx->old, mm_ops),
> @@ -1032,13 +1038,32 @@ static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
>  
>  int kvm_pgtable_stage2_unmap(struct kvm_pgtable *pgt, u64 addr, u64 size)
>  {
> +	int ret;
> +	struct stage2_unmap_data unmap_data = {
> +		.pgt = pgt,
> +		/*
> +		 * If FEAT_TLBIRANGE is implemented, defer the individial PTE
> +		 * TLB invalidations until the entire walk is finished, and
> +		 * then use the range-based TLBI instructions to do the
> +		 * invalidations. Condition this upon S2FWB in order to avoid
> +		 * a page-table walk again to perform the CMOs after TLBI.
> +		 */
> +		.skip_pte_tlbis = system_supports_tlb_range() &&
> +					stage2_has_fwb(pgt),

Why can't the underlying walker just call these two helpers directly?
There are static keys behind these...

> +	};
>  	struct kvm_pgtable_walker walker = {
>  		.cb	= stage2_unmap_walker,
> -		.arg	= pgt,
> +		.arg	= &unmap_data,
>  		.flags	= KVM_PGTABLE_WALK_LEAF | KVM_PGTABLE_WALK_TABLE_POST,
>  	};
>  
> -	return kvm_pgtable_walk(pgt, addr, size, &walker);
> +	ret = kvm_pgtable_walk(pgt, addr, size, &walker);
> +	if (unmap_data.skip_pte_tlbis)
> +		/* Perform the deferred TLB invalidations */
> +		kvm_call_hyp(__kvm_tlb_flush_vmid_range, pgt->mmu,
> +				addr, addr + size);
> +
> +	return ret;
>  }
>  
>  struct stage2_attr_data {
> -- 
> 2.40.0.634.g4ca3ef3211-goog
> 

-- 
Thanks,
Oliver