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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 F1701C27C52 for ; Tue, 4 Jun 2024 08:52:46 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=Mh20iy/f; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4VtkrF1G89z3cWN for ; Tue, 4 Jun 2024 18:52:45 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=Mh20iy/f; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=conor@kernel.org; receiver=lists.ozlabs.org) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4VtkqS0shmz3cF6 for ; Tue, 4 Jun 2024 18:52:04 +1000 (AEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 369AD6121A; Tue, 4 Jun 2024 08:52:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02151C2BBFC; Tue, 4 Jun 2024 08:51:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717491121; bh=X5VEKcXjsckL7bzsB4I2+5w7z1/yIThVP4y03Rift7Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Mh20iy/fPgoKsPFqkHOMkSvPPs3YobSnTzSECvBMzNm1M8s6vO83AlQC6ilY4EOTy 8sOXH1quEckXBhwBGWJj3cHU+7AJwHqGK3p8fjuVfk/jjnSzsPPyPutWZjpiLaoAyt gCdMIRxqqGOm0zxE4aSYMab0Wodh06NeE+MsysKpcDwBDbIlcnfS/wkLiVdVzhzICG 4UjcQOTTx+aFwRJE1QaD8Cvt4dl3qLXOUDKmxsy7E1fx9TesQtzL9Q+NmezjMQehNS 0WMvz7jO6i8duGQNOX4hQOm+ZTVOc7wkWM1vHVgf8whVZyCCBz2ju8SWZpi8Hlqbp4 o2gZF74Dfgnvw== Date: Tue, 4 Jun 2024 09:51:55 +0100 From: Conor Dooley To: Alexandre Ghiti Subject: Re: [External] [PATCH RFC/RFT v2 3/4] riscv: Stop emitting preventive sfence.vma for new vmalloc mappings Message-ID: <20240604-dazzling-envy-1dcf111eb2c5@spud> References: <20240131155929.169961-1-alexghiti@rivosinc.com> <20240131155929.169961-4-alexghiti@rivosinc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v+mLtQDAp6jKleQy" Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-riscv@lists.infradead.org, Thomas Bogendoerfer , linux-mm@kvack.org, Catalin Marinas , Paul Walmsley , linux-kernel@vger.kernel.org, Nicholas Piggin , linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Matt Evans , Albert Ou , Palmer Dabbelt , yunhui cui , Ved Shanbhogue , Andrew Morton , Will Deacon , Dylan Jhong , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" --v+mLtQDAp6jKleQy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2024 at 09:17:26AM +0200, Alexandre Ghiti wrote: > On Tue, Jun 4, 2024 at 9:15=E2=80=AFAM Alexandre Ghiti wrote: > > On Tue, Jun 4, 2024 at 8:21=E2=80=AFAM yunhui cui wrote: > > > > > > As for the current status of the patch, there are two points that can > > > be optimized: > > > 1. Some chip hardware implementations may not cache TLB invalid > > > entries, so it doesn't matter whether svvptc is available or not. Can > > > we consider adding a CONFIG_RISCV_SVVPTC to control it? >=20 > That would produce a non-portable kernel. But I'm not opposed to that > at all, let me check how we handle other extensions. Maybe @Conor > Dooley has some feedback here? To be honest, not really sure what to give feedback on. Could you elaborate on exactly what the option is going to do? Given the portability concern, I guess you were proposing that the option would remove the preventative fences, rather than your current patch that removes them via an alternative? I don't think we have any extension related options that work like that at the moment, and making that an option will just mean that distros that look to cater for multiple platforms won't be able to turn it on. Thanks, Conor. --v+mLtQDAp6jKleQy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZl7VpwAKCRB4tDGHoIJi 0htmAP9lKpWaps7KNiXD+LLzGjaogNRPLVfDE+cLSH8OGRjL0gD/b1+iNEj7/u9+ OImeR7875AIcwdnxddUdj3oiiMB/6AA= =s00j -----END PGP SIGNATURE----- --v+mLtQDAp6jKleQy--