From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CDC0E283FC0; Tue, 6 May 2025 14:52:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746543123; cv=none; b=LWQ9jvRc8vaQ+eowKouBty7Ze92+Whp1pxjVuZ4GIRweDcNNrmtZ6ivBKJ15TPiJ2sI7v7JA+va7oeHM3yxKMkuuMkt0+2rV9uVZwzPwBVFIlsrb6/OU58K5Dx4Uaj4yn/xg877DulXmGgv/ZIdEGHvUUdzW8gH2NSQhveXRFrE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746543123; c=relaxed/simple; bh=K+msrNcjslK8gX9r4hYRpdwGYgkStkMVQt+IJpV0k90=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Sb5AnwafSHMEQBHtvSVeXrcSF34YH3qW/ytA2fB5ZiYga8W/jwPzW3A83g0LftuMUfeqZiXpUroRiWB0bHecxEaWUi5BcUykG/hSMvsmkftjWMg8AjbrK9eOQqvru0IotpBw6lltaXVNnKIcGp9HtTUuCWXRhe7zbeXjAz1Ovyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RVNAFcGx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RVNAFcGx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49002C4CEE4; Tue, 6 May 2025 14:52:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746543123; bh=K+msrNcjslK8gX9r4hYRpdwGYgkStkMVQt+IJpV0k90=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RVNAFcGxw3dHYXOyVRXh5fivxKa/N2jk5eKMAvqLohOS4UebVRQrVGdWVHoZgRJTv eVq6S9v7qPUlLp7O8jG2nR0PfRuQQZn4IG4n8Ftb4ml38TzmSYyqa4YwBI0wfGTkaC X4lbuLwA01LMCckukXI1VbLv38F57prx/ajNK0b/ez39T2+d4ZhxYdgq5D1ly9Gmw2 +9IG3wM2dnjxxMFiVrKJhwZcb3ptz9+ga3aMhBTKeFQMhGMbhZMPLoMD4S2LQwJkXq OAAY4auq4X0QFYWLpPi3+HrDs2nzjIC8sdXdPoM2ehDVO5Asj84WtfcCvz7VfbN5Tx Sb/tZQ1xVT76g== 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.95) (envelope-from ) id 1uCJeK-00CHhs-JT; Tue, 06 May 2025 15:52:00 +0100 Date: Tue, 06 May 2025 15:51:59 +0100 Message-ID: <86cyclhjw0.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: =?UTF-8?B?TWlrb8WCYWo=?= Lenczewski , ryan.roberts@arm.com, suzuki.poulose@arm.com, yang@os.amperecomputing.com, corbet@lwn.net, catalin.marinas@arm.com, jean-philippe@linaro.org, robin.murphy@arm.com, joro@8bytes.org, akpm@linux-foundation.org, paulmck@kernel.org, mark.rutland@arm.com, joey.gouly@arm.com, james.morse@arm.com, broonie@kernel.org, oliver.upton@linux.dev, baohua@kernel.org, david@redhat.com, ioworker0@gmail.com, jgg@ziepe.ca, nicolinc@nvidia.com, mshavit@google.com, jsnitsel@redhat.com, smostafa@google.com, kevin.tian@intel.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev Subject: Re: [RESEND PATCH v6 1/3] arm64: Add BBM Level 2 cpu feature In-Reply-To: <20250506142508.GB1197@willie-the-truck> References: <20250428153514.55772-2-miko.lenczewski@arm.com> <20250428153514.55772-4-miko.lenczewski@arm.com> <20250506142508.GB1197@willie-the-truck> 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-kernel@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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: will@kernel.org, miko.lenczewski@arm.com, ryan.roberts@arm.com, suzuki.poulose@arm.com, yang@os.amperecomputing.com, corbet@lwn.net, catalin.marinas@arm.com, jean-philippe@linaro.org, robin.murphy@arm.com, joro@8bytes.org, akpm@linux-foundation.org, paulmck@kernel.org, mark.rutland@arm.com, joey.gouly@arm.com, james.morse@arm.com, broonie@kernel.org, oliver.upton@linux.dev, baohua@kernel.org, david@redhat.com, ioworker0@gmail.com, jgg@ziepe.ca, nicolinc@nvidia.com, mshavit@google.com, jsnitsel@redhat.com, smostafa@google.com, kevin.tian@intel.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@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 Tue, 06 May 2025 15:25:09 +0100, Will Deacon wrote: >=20 > On Mon, Apr 28, 2025 at 03:35:14PM +0000, Miko=C5=82aj Lenczewski wrote: > > The Break-Before-Make cpu feature supports multiple levels (levels 0-2), > > and this commit adds a dedicated BBML2 cpufeature to test against > > support for, as well as a kernel commandline parameter to optionally > > disable BBML2 altogether. > >=20 > > This is a system feature as we might have a big.LITTLE architecture > > where some cores support BBML2 and some don't, but we want all cores to > > be available and BBM to default to level 0 (as opposed to having cores > > without BBML2 not coming online). > >=20 > > To support BBML2 in as wide a range of contexts as we can, we want not > > only the architectural guarantees that BBML2 makes, but additionally > > want BBML2 to not create TLB conflict aborts. Not causing aborts avoids > > us having to prove that no recursive faults can be induced in any path > > that uses BBML2, allowing its use for arbitrary kernel mappings. > > Support detection of such CPUs. > >=20 > > Signed-off-by: Miko=C5=82aj Lenczewski > > Reviewed-by: Suzuki K Poulose > > Reviewed-by: Ryan Roberts > > --- > > .../admin-guide/kernel-parameters.txt | 3 + > > arch/arm64/Kconfig | 19 +++++ > > arch/arm64/include/asm/cpucaps.h | 2 + > > arch/arm64/include/asm/cpufeature.h | 5 ++ > > arch/arm64/kernel/cpufeature.c | 71 +++++++++++++++++++ > > arch/arm64/kernel/pi/idreg-override.c | 2 + > > arch/arm64/tools/cpucaps | 1 + > > 7 files changed, 103 insertions(+) > >=20 > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Document= ation/admin-guide/kernel-parameters.txt > > index d9fd26b95b34..2749c67a4f07 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -449,6 +449,9 @@ > > arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of > > 32 bit applications. > > =20 > > + arm64.nobbml2 [ARM64] Unconditionally disable Break-Before-Make Level > > + 2 support >=20 > Hmm, I'm not sure we really want this. It opens up the door for folks to > pass 'id_aa64mmfr2.bbm=3D2' without updating the allow-list which feels > like it's going to make crashes harder to reason about. Passing id_aa64mmfr2.bbm=3D2 shouldn't have any effect if the HW doesn't advertise it already, as you can only downgrade features. Trying to upgrade features should leave a nastygram in the kernel log. M. --=20 Without deviation from the norm, progress is not possible.