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 1EDDF49550F; Fri, 16 Oct 2026 12:35:43 +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=1792154146; cv=none; b=i5bxzYj/Slt4JeLvHqedzxT4y/8q+4lPH4cHVhHkXGK0LgYeR850DSkYEO0H96pmEo4h8nS8P/brXuf5y0X7GrCsScpeZzpyTpmnY8INYPkw2nQvNyxqz8JPmKnugyBJBJ3TklPGWilnRMJhhF/D0es/8xU12EhWMd0M3CV1hoM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792154146; c=relaxed/simple; bh=qo57Y8sVuKDQtzxvYWzxBNYYknPPaoFolB5m+yVIP+Y=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=JCJZGrA2H9I3eIDCMdKyPmZ4B05K6FlQ+FpQEzjG81ahBjMgHc2D99TQFHya58iGMEFVKSgQaRuPcXHcaEtVL/WrR04kGw5uP1U/r1MyLwwuKq2i6lQFBNeEQWsussoWElPfcrAbomkRx1ekZ3DBhuLPtcKldoWlR0qIQtFzRqI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TYgalTsr; 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="TYgalTsr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 646BA1F000C5; Fri, 16 Oct 2026 12:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792154143; bh=yod+OUSk06H1G1niXjYGWKR93BqD83B+Eqbab+MOY7o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=TYgalTsrhorxXtmw0FD8z8F+VsI/95+mO9H0VY2k2LQXkrTQtYHbheRUAHwl2oa+Y /8T1sVCa2H97Z6c4QFWw97rdZ0JSVGOFKUUrFqQKNcLtU3WuxJWp18K6h0JPDMfHny EEtdACS+W7TDB64pqsqs0z0BQ0UddxDtodFZ8rSMYGGeuY48so6N7q7ATNxgD+9u/F bqt2uvQDex+KXq2wVRUQXQZwOQ6G3oVcAu5pFZOSjggS1rIJg8wN/ss+H+B7zFdxo5 NcLekinMgISAi9NdfLR2cyS4o1QoKmW+c5iGUTGC56IYxd6w4Z0UO+mHNOq6d92aAY el6CmbKqrZGXQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xHh9w-00000003kPF-3rh9; Fri, 16 Oct 2026 12:35:41 +0000 Date: Fri, 16 Oct 2026 13:35:40 +0100 Message-ID: <86bj8t257n.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: Tomohiro Misono , Catalin Marinas , Will Deacon , Jonathan Corbet , Shuah Khan , Randy Dunlap , Thomas Gleixner , Radu Rendec , Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Kohei Enju , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-perf-users@vger.kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v2 2/4] arm64: tlb: Add tlbi workaround for FUJITSU-MONAKA Erratum E#030001 In-Reply-To: References: <20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com> <20261016-monaka-fix-for-upstream-v2-2-fc7ede7f9f48@fujitsu.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, misono.tomohiro@fujitsu.com, catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org, tglx@kernel.org, radu@rendec.net, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, enju.kohei@fujitsu.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-perf-users@vger.kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 16 Oct 2026 12:50:17 +0100, Mark Rutland wrote: > > On Fri, Oct 16, 2026 at 07:00:46PM +0900, Tomohiro Misono wrote: > > FUJITSU-MONAKA Erratum E#030001 affects FUJITSU-MONAKA CPU > > when using TLBI range operations. > > > > On affected FUJITSU-MONAKA CPUs, range-based TLBI operations > > targeting a VA or IPA may fail to invalidate TLB entries when > > addr[34:29] == all 1 && addr[28:0] == 0 for 512MB mappings. > > The affected instructions are: > > RVA[L]E{1,2,3}*, RVAA[L]E1*, and RIPAS2[L]E1*. > > > > Work around the erratum by issuing additional non-range > > TLBI instructions corresponding to the affected VA or IPA > > range-based TLBI operations. > > > > Signed-off-by: Tomohiro Misono > > As Will and I suggested last time, we'd prefer to disable range > operations on these parts (and ensure that the relevant ID field is > hidden from KVM guests). > > Regardless of whether eventually accept the approach you propose here, > we first need something simple to backport to stable trees (as I assume > you'll want to run standard Linux distributions on this hardware). The > TLB invalidation code has changed a lot over time, and I don't think > it's practical or sensible to backport this patch. > > As a first step, I think we should simply disable the use of range > operations on these parts, and ensure that KVM hides the relevant ID > field. After that, we can consider optimizing the workaround, as you > propose here. > > Marc, does that align with your expectations? Yes. I'd rather we start with a clean slate so that an unsuspecting guest cannot get things wrong because it doesn't know about the erratum. Anything else is icing on the cake that is not desirable at this stage. > Is there an existing pattern to follow for hiding the ID field? Ideally, TLBI_RANGE would be removed from the ID_AA64ISAR0_EL1 copy that the kernel has, and KVM would simply inherit this. I'm not sure we have a good way to do that other than doing horrible things with the override masks. Otherwise, something as simple as forcing the ID_AA64ISAR0_EL1 reset value in sys_regs.c would work. M. -- Without deviation from the norm, progress is not possible.