From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 34C5D28F5 for ; Sat, 11 Jul 2026 00:04:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783728267; cv=none; b=krp74whmJPX4c5hJAGKlLgyqoccxu5kpL603XdGv5WkwY7hdp5LW60VzYvTlpmjm7I5ZRYyR/FV8YSWbnlRPr8XUU/h+9LAnGSkwdlEeq+xbiqlzmG57zl6H8XTO0OyteACnqfCB6ny1PfXE+aKcxoN+Or3FJlC2A9oY568VTs4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783728267; c=relaxed/simple; bh=fjCNr7EXOOy0djbXM6anbSUGWMXRUElhoULOqJ3oicA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=D+J0LZyzRoxJTOzLe9OJqGJAtuuH+gT3T6Kpo+yEeJm42e5yKaBMyTXgEPpItvSaEhtWOrV8mOQynlTYGU6KjQxymDx/7X+hWiyB6CNaEyIKCpGSxmZH4T2Ua0aFDlB/wd9eKTugmk5jTVpaUTR9FMTQt4U4pI6Q+YETTQ1KiTM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ci6t2GSi; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ci6t2GSi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 556671F000E9; Sat, 11 Jul 2026 00:04:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783728265; bh=NIBkWpvs94ifP9DOH15o1FfiAVlDV0ggO/H3owjMavQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ci6t2GSikykjNwFxmDpqQYwroTakRV6up3m8CXbJsjetN0ReFJ4cKT7qmsSxxqqJH hj4iSaeL4shGPMcRJ6l2PO9ONZSMx5Mb2BbtkKOPUw2pomQkS8uxrfqnMNqiBDFzHy V5Kva4ZWD4HpEPEt8aG0svrMLfHY33qQZjg8zQ2VSlO4iGOppgxlMP+BG5c/+T3m0F et1jaDwJwkVJ7VkgbPMRjCAXBVnckDos0z42gHvZZEaG5/bvM39EFn7nXnke4tIpJC xwdrebTIdRDWMKC9IikiqKv5Al1PaiX3RR1Bv0KlT7r9NN7TpZt9mY1lAaBUKHGH3c wfCCmi/7tFVig== Date: Fri, 10 Jul 2026 18:04:22 -0600 (MDT) From: Paul Walmsley To: Xu Lu cc: paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, apw@canonical.com, joe@perches.com Subject: Re: [PATCH RESEND 1/2] riscv: mm: Apply svinval in update_mmu_cache() In-Reply-To: <20250901114141.5438-2-luxu.kernel@bytedance.com> Message-ID: References: <20250901114141.5438-1-luxu.kernel@bytedance.com> <20250901114141.5438-2-luxu.kernel@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi, On Mon, 1 Sep 2025, Xu Lu wrote: > Only flush tlb of the specified mm, and apply svinval if available. > > Signed-off-by: Xu Lu I wound up splitting this into two separate patches, rather than one patch, since there seem to be two orthogonal changes. The first change restricts the sfence.vma to a particular ASID (below). The second change involves the Svinval path, and is sent in a subsequent message. What do you think? - Paul From: Xu Lu Date: Mon, 1 Sep 2025 19:41:40 +0800 Subject: [PATCH 1/2] riscv: mm: flush TLB by ASID in update_mmu_cache_range() Only flush the TLB of the specified mm (via local_flush_tlb_page_asid) Signed-off-by: Xu Lu Link: https://patch.msgid.link/20250901114141.5438-2-luxu.kernel@bytedance.com [pjw@kernel.org: split the non-Svinval code in the original into this patch; update description] Signed-off-by: Paul Walmsley --- arch/riscv/include/asm/pgtable.h | 7 +++++-- arch/riscv/include/asm/tlbflush.h | 5 +++++ arch/riscv/mm/tlbflush.c | 5 ----- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 5d5756bda82e..755495a542cc 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -568,6 +568,8 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf, struct vm_area_struct *vma, unsigned long address, pte_t *ptep, unsigned int nr) { + unsigned long asid; + /* * Svvptc guarantees that the new valid pte will be visible within * a bounded timeframe, so when the uarch does not cache invalid @@ -583,10 +585,11 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf, * Relying on flush_tlb_fix_spurious_fault would suffice, but * the extra traps reduce performance. So, eagerly SFENCE.VMA. */ + asid = get_mm_asid(vma->vm_mm); while (nr--) - local_flush_tlb_page(address + nr * PAGE_SIZE); - + local_flush_tlb_page_asid(address + nr * PAGE_SIZE, asid); } + #define update_mmu_cache(vma, addr, ptep) \ update_mmu_cache_range(NULL, vma, addr, ptep, 1) diff --git a/arch/riscv/include/asm/tlbflush.h b/arch/riscv/include/asm/tlbflush.h index eed0abc40514..7c2cd5cc92d3 100644 --- a/arch/riscv/include/asm/tlbflush.h +++ b/arch/riscv/include/asm/tlbflush.h @@ -15,6 +15,11 @@ #define FLUSH_TLB_NO_ASID ((unsigned long)-1) #ifdef CONFIG_MMU +static inline unsigned long get_mm_asid(struct mm_struct *mm) +{ + return mm ? cntx2asid(atomic_long_read(&mm->context.id)) : FLUSH_TLB_NO_ASID; +} + static inline void local_flush_tlb_all(void) { __asm__ __volatile__ ("sfence.vma" : : : "memory"); diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c index 8404530ec00f..73c226f719c7 100644 --- a/arch/riscv/mm/tlbflush.c +++ b/arch/riscv/mm/tlbflush.c @@ -110,11 +110,6 @@ static void __ipi_flush_tlb_range_asid(void *info) local_flush_tlb_range_asid(d->start, d->size, d->stride, d->asid); } -static inline unsigned long get_mm_asid(struct mm_struct *mm) -{ - return mm ? cntx2asid(atomic_long_read(&mm->context.id)) : FLUSH_TLB_NO_ASID; -} - static void __flush_tlb_range(struct mm_struct *mm, const struct cpumask *cmask, unsigned long start, unsigned long size, -- 2.53.0