linux-kernel - Re: [PATCH v2 3/4] riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlb

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: <20230728-fragrant-slogan-c0d5fe419148@wendy>
Date:   Fri, 28 Jul 2023 14:50:50 +0100
From:   Conor Dooley <conor.dooley@...rochip.com>
To:     Alexandre Ghiti <alexghiti@...osinc.com>
CC:     Will Deacon <will@...nel.org>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nick Piggin <npiggin@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Mayuresh Chitale <mchitale@...tanamicro.com>,
        Vincent Chen <vincent.chen@...ive.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        <linux-arch@...r.kernel.org>, <linux-mm@...ck.org>,
        <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] riscv: Make __flush_tlb_range() loop over pte
 instead of flushing the whole tlb

On Thu, Jul 27, 2023 at 08:55:52PM +0200, Alexandre Ghiti wrote:
> Currently, when the range to flush covers more than one page (a 4K page or
> a hugepage), __flush_tlb_range() flushes the whole tlb. Flushing the whole
> tlb comes with a greater cost than flushing a single entry so we should
> flush single entries up to a certain threshold so that:
> threshold * cost of flushing a single entry < cost of flushing the whole
> tlb.
> 

> This threshold is microarchitecture dependent and can/should be
> overwritten by vendors.

Please remove the latter part of this, as there is no infrastructure for
this at present, nor likely in the immediate future.

> Co-developed-by: Mayuresh Chitale <mchitale@...tanamicro.com>
> Signed-off-by: Mayuresh Chitale <mchitale@...tanamicro.com>
> Signed-off-by: Alexandre Ghiti <alexghiti@...osinc.com>
> ---
>  arch/riscv/mm/tlbflush.c | 41 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
> index 3e4acef1f6bc..8017d2130e27 100644
> --- a/arch/riscv/mm/tlbflush.c
> +++ b/arch/riscv/mm/tlbflush.c
> @@ -24,13 +24,48 @@ static inline void local_flush_tlb_page_asid(unsigned long addr,
>  			: "memory");
>  }
>  
> +/*
> + * Flush entire TLB if number of entries to be flushed is greater
> + * than the threshold below.

>     Platforms may override the threshold
> + * value based on marchid, mvendorid, and mimpid.

And this too, as there is no infrastructure for this the comment is
misleading. This kind of thing should only be added when there is
actually a mechanism for doing so.

I did say I would think about how to do this, but I have not come up
with something. I dislike using the marchid/mvendorid/mimpid stuff if we
can avoid it, as there's no control over what actually gets put in there,
especially if people are going to use the open souce cores.

Do we even, unless under extreme duress, want to allow setting custom
values here via firmware? Sounds like a recipe for 1200 different
alternatives or a big LUT...

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)