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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 730E8C36014 for ; Tue, 1 Apr 2025 12:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aKtsW90Gsf4uFRbrKccOWlVGEPm8dvLQMvDNzcrztUM=; b=xA9hvmc1+WtbPBh1XDYTZxcgWM i3XUY5r3IGIK+oe0+d2DrGb/jXpbiK13b2uRMz+UZdNBem2y8XQKu0uyZKwcBWoVtqXhh01AEpd1Y FepbsptSkz89tBMVnIIR+l3jbadeM8/RmPxZFGIqZjBnTRcBTPmNMrycTJYd3rMaxLvGU+qLV9hm1 I1JQAGgCZF1kWWBS7G+SsLuCdfAQh6rXEJ0uiQpBu5fAMFD6yvqhvVh4nfzRI9BkJOc7ctTIUlvpg m9P13n4CKlW+hCdQaax4OgT3+9jvNj3X7xj6nBGi1JddIyUkB8MNolgu8KVMw753TSmt7W32MSfOd 6Y0hxFiw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1tzao6-00000003HSp-3x3p; Tue, 01 Apr 2025 12:33:30 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98.1 #2 (Red Hat Linux)) id 1tzaQV-00000002x6y-2bRh for linux-arm-kernel@lists.infradead.org; Tue, 01 Apr 2025 12:09:09 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D47D65C0FDF; Tue, 1 Apr 2025 12:06:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7ABC9C4CEE4; Tue, 1 Apr 2025 12:09:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743509345; bh=ymWxHJh8c39lUSfpJKhiztgKbex2vJHoHlvT/jj0qw8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=c8Xl44RdgcqzUYzufvsO+bwS9V8stcy/6+rGYQOF6yHaGEav3H/Xtu3wGshLiRTE5 MnSNn/I5d6+jSWUz+jjyMEVCh0VlcCz8yGoolR6YcsqAHXJhumxidmXZWM4kWWaokZ oGblYRCEzVEufXJDPWR3a+dI/utNj/xC3fblwY4MAPkwNLx8MxKtVPXPHlBigmbdqX Dl+9ECoE8BkK5WJHJeZkdzOPcPKPNGfl5pimMqHQowo2v2q6fLWO+k+0IkEsEaMwrB 1wCChtF/BBfJYSsqEhIK0X1LS8bSlC2Hn50wR0B54zSPoJrDRFRBp0teRoajsfCpMF v3slwexRKFk0A== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-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 1tzaQR-001Jxh-F1; Tue, 01 Apr 2025 13:09:03 +0100 Date: Tue, 01 Apr 2025 13:09:04 +0100 Message-ID: <87plhwytgf.wl-maz@kernel.org> From: Marc Zyngier To: Xi Ruoyao Cc: Anshuman Khandual , James Morse , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Shameer Kolothum , Mingcong Bai Subject: Re: [PATCH] arm64: Add overrride for MPAM In-Reply-To: <46ed31b37b4b92720b26be66f3e6366a714024cf.camel@xry111.site> References: <20250401055650.22542-1-xry111@xry111.site> <409f6d27-3efe-4c45-8319-d360ded80f16@arm.com> <46ed31b37b4b92720b26be66f3e6366a714024cf.camel@xry111.site> 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) 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: xry111@xry111.site, anshuman.khandual@arm.com, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, shameerali.kolothum.thodi@huawei.com, jeffbai@aosc.io X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250401_050907_748765_01980E0C X-CRM114-Status: GOOD ( 34.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 01 Apr 2025 12:47:03 +0100, Xi Ruoyao wrote: >=20 > On Tue, 2025-04-01 at 14:04 +0530, Anshuman Khandual wrote: > > On 4/1/25 11:26, Xi Ruoyao wrote: > > > As the message of the commit 09e6b306f3ba ("arm64: cpufeature: discov= er > > > CPU support for MPAM") already states, if a buggy firmware fails to > > > either enable MPAM or emulate the trap as if it were disabled, the > > > kernel will just fail to boot.=C2=A0 While upgrading the firmware sho= uld be > > > the best solution, we have some hardware of which the vender have made > > > no response 2 months after we requested a firmware update.=C2=A0 Allow > > > overriding it so our devices don't become some e-waste. > > > > There could be similar problems, where firmware might not enable arch > > features as required. Just wondering if there is a platform policy in > > place for enabling id-reg overrides for working around such scenarios > > to prevent a kernel crash etc ? >=20 > In https://lore.kernel.org/all/87jzcfsuep.wl-maz@kernel.org/: >=20 > > For such cases, when MPAM is incorrectly advertised, can we have ker= nel > > command line parameter like mpam=3D0 to override it's detection? > =20 > We could, but only when we can confirm what the problem is. >=20 > And there was prior arts like: >=20 > commit 892f7237b3ffb090f1b1f1e55fe7c50664405aed > Author: Marc Zyngier > Date: Wed Jul 20 11:52:19 2022 +0100 >=20 > arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr} > =20 > Even if we are now able to tell the kernel to avoid exposing SVE/SME > from the command line, we still have a couple of places where we > unconditionally access the ZCR_EL1 (resp. SMCR_EL1) registers. > =20 > On systems with broken firmwares, this results in a crash even if > arm64.nosve (resp. arm64.nosme) was passed on the command-line. > =20 > To avoid this, only update cpuinfo_arm64::reg_{zcr,smcr} once > we have computed the sanitised version for the corresponding > feature registers (ID_AA64PFR0 for SVE, and ID_AA64PFR1 for > SME). This results in some minor refactoring. That particular patch has caused quite a few issues, see d3c7c48d004f. So don't use it as a reference. Now, while I think an option is probably acceptable in the face of an unresponsive vendor, I don't think the way you implement it is the correct approach. It should be possible to handle the override in the assembly code, like we do for other bits and pieces, and deal with MPAMIDR_EL1 later down the line, once the sanitised ID registers are known to be valid. Overall, we don't have a great story with feature-specific ID registers that can undef when the feature isn't present (such as MPAMIDR_EL1, SMIDR_EL1, PMSIDR_EL1), and we should adopt a common behaviour for those. Thanks, M. --=20 Jazz isn't dead. It just smells funny.