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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50096C001DF for ; Thu, 3 Aug 2023 09:25:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234464AbjHCJZg (ORCPT ); Thu, 3 Aug 2023 05:25:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229792AbjHCJZb (ORCPT ); Thu, 3 Aug 2023 05:25:31 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1587E211B for ; Thu, 3 Aug 2023 02:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1691054727; x=1722590727; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Wq+v2Oj+6Mxd2a//oJirAmmObJX/ETHVeQsh34JFG4Q=; b=T3v+bpjSEb//g/JN2G2zeMeaARkUgZSv2oZBfa4sbTCfYmwjs5KsuJJY EL76U6LvJXWhu9OFl8Nai7Wvx16azeWC8ncjPZhOP+W0tMuJ/kbpV46eZ wZIjExfCuTMzo3KILUtba3VxWiLZa58AOfz0VSodgXjKgTQMRrwNr43cx 9XC4ayKTczs0Sp4DwMoI8dbAqGEj/U+cO5xQW7Hcl5IUaufu61G2G/jzX drNF4CSecdi0G9AJ9LaGvSLcGz2XwyW4r/bT6Zu3Z+jpCFcawNfSCAWw2 v5ojOBzvUzrhukCaJ1nGwpnAcAnHNbzfGaFyVAUvVmdX4BlQ+ISfiNLBD g==; X-IronPort-AV: E=Sophos;i="6.01,251,1684825200"; d="asc'?scan'208";a="239547799" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 03 Aug 2023 02:25:27 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Thu, 3 Aug 2023 02:25:25 -0700 Received: from wendy (10.10.115.15) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21 via Frontend Transport; Thu, 3 Aug 2023 02:25:24 -0700 Date: Thu, 3 Aug 2023 10:24:48 +0100 From: Conor Dooley To: dylan CC: Guo Ren , Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , , Subject: Re: [PATCH -fixes] riscv: Implement flush_cache_vmap() Message-ID: <20230803-stadium-unusable-6cf00e35ec22@wendy> References: <20230725132246.817726-1-alexghiti@rivosinc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nozptzZSf18sXWvu" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nozptzZSf18sXWvu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 03, 2023 at 05:14:15PM +0800, dylan wrote: > On Sun, Jul 30, 2023 at 01:08:17AM -0400, Guo Ren wrote: > > On Tue, Jul 25, 2023 at 9:22=E2=80=AFAM Alexandre Ghiti wrote: > > > > > > The RISC-V kernel needs a sfence.vma after a page table modification:= we > > > used to rely on the vmalloc fault handling to emit an sfence.vma, but > > > commit 7d3332be011e ("riscv: mm: Pre-allocate PGD entries for > > > vmalloc/modules area") got rid of this path for 64-bit kernels, so no= w we > > > need to explicitly emit a sfence.vma in flush_cache_vmap(). > > > > > > Note that we don't need to implement flush_cache_vunmap() as the gene= ric > > > code should emit a flush tlb after unmapping a vmalloc region. > > > > > > Fixes: 7d3332be011e ("riscv: mm: Pre-allocate PGD entries for vmalloc= /modules area") > > > Signed-off-by: Alexandre Ghiti > > > --- > > > arch/riscv/include/asm/cacheflush.h | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include= /asm/cacheflush.h > > > index 8091b8bf4883..b93ffddf8a61 100644 > > > --- a/arch/riscv/include/asm/cacheflush.h > > > +++ b/arch/riscv/include/asm/cacheflush.h > > > @@ -37,6 +37,10 @@ static inline void flush_dcache_page(struct page *= page) > > > #define flush_icache_user_page(vma, pg, addr, len) \ > > > flush_icache_mm(vma->vm_mm, 0) > > > > > > +#ifdef CONFIG_64BIT > > > +#define flush_cache_vmap(start, end) flush_tlb_kernel_range(start,= end) > > Sorry, I couldn't agree with the above in a PIPT cache machine. It's > > not worth for. > >=20 > > It would reduce the performance of vmap_pages_range, > > ioremap_page_range ... API, which may cause some drivers' performance > > issues when they install/uninstall memory frequently. > >=20 >=20 > Hi All, >=20 > I think functional correctness should be more important than system perfo= rmance > in this case. The "preventive" SFENCE.VMA became necessary due to the RIS= C-V > specification allowing invalidation entries to be cached in the TLB. We are at -rc4 and this stuff is broken. Taking the bigger hammer, which can be reverted later when a more targeted fix shows up, to make sure that v6.5 doesn't end up broken, sounds rather prudent. Otherwise, the original commit should probably be reverted. > The problem[1] we are currently encountering is caused by not updating th= e TLB > after the page table is created, and the solution to this problem can onl= y be > solved by updating the TLB immediately after the page table is created. >=20 > There are currently two possible approaches to flush TLB: > 1. Flush TLB in flush_cache_vmap() > 2. Flush TLB in arch_sync_kernel_mappings() >=20 > But I'm not quite sure if it's a good idea to operate on the TLB inside f= lush_cache_vmap(). > The name of this function indicates that it should be related to cache op= erations, maybe > it would be more appropriate to do TLB flush in arch_sync_kernel_mappings= ()? >=20 > [1]: http://lists.infradead.org/pipermail/linux-riscv/2023-August/037503.= html --nozptzZSf18sXWvu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZMtyYAAKCRB4tDGHoIJi 0u/zAP97NUn9kei7lOztrs80Kjn5bphODbu+95FYx7AzN9ltnwEAsbXegqjY7oxy Y54cRpYdqg38D3rmo30B74v1GcEJWA0= =imZu -----END PGP SIGNATURE----- --nozptzZSf18sXWvu--