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 76A421DB37F; Tue, 17 Dec 2024 08:27:12 +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=1734424032; cv=none; b=ESR+QrwEOL/8FujZc8aL6Bf8tVXiUXx/RAvD5u2wcheFwMFnTrMOyjn7L+qRwxD+ZVP7+8Co50P0KSKjD3HxWf4gX9pvmznUJYprg817A+Ep1TkjlFfrETK2oR6hPF/lbhUAeg5NXzRh8/qK8LbuHZqrm1diXLBzkFOFfgcCJpo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734424032; c=relaxed/simple; bh=j2ll6ZoLtO5dCF3DRciFEfrk8Jcl0N+PKw0EN5ykTsc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Nb198LeDOvU/72qnxKxDKl7+mG/qo4nWs15e4t3xy9FVdBVGjIXaZkmHBtAwbYObAYma3f6HLFRnQwWsonSY6rPF+IdAwPH4GqvqTi2iu9amflfqoKbFzmpjbe9MBRLjAhDRPre32d39r9WreABnnN0NIy/W9Pa1UGEnz4L57YU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WtL3lBFW; 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="WtL3lBFW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA1BDC4CED3; Tue, 17 Dec 2024 08:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734424032; bh=j2ll6ZoLtO5dCF3DRciFEfrk8Jcl0N+PKw0EN5ykTsc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WtL3lBFWvSp7ETcABRdNez3SaGOnQcpyrWYLzcAH08+LPP3KEjZspeF+l1464yuE0 968ZJXWMoPSvADpCunue2ldmQLcEvNvOu8dtLkZ/ChlHgqczPKji6IPSOitSzT/kri lxRnhyRabv/Ir1YfkatNFUznnrm58wCc8nJd4w8FRqc3I07Ekkc3JZzM7p0zWAxy0B 8jRKke/V42mGXrQ9kGcy499leaKtmdIytTKGhUE4SEGmvJZYBgZ+YWasXYPDIYzWOJ HBma3F6pXZhc0W7jW/5AvWnaVFtX4GnkrCbdi8Wmzz4RC44KLOvkIKLaai6PmQFCst h6gp6j52Tdscw== Received: from [82.132.185.145] (helo=wait-a-minute.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 1tNSv7-004TZx-P7; Tue, 17 Dec 2024 08:27:09 +0000 Date: Tue, 17 Dec 2024 08:27:07 +0000 Message-ID: <877c7ysois.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Peter Collingbourne , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu() In-Reply-To: <20241216-arm64-fix-boot-cpu-smidr-v2-1-a99ffba2c37f@kernel.org> References: <20241216-arm64-fix-boot-cpu-smidr-v2-1-a99ffba2c37f@kernel.org> 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/29.4 (x86_64-pc-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=US-ASCII X-SA-Exim-Connect-IP: 82.132.185.145 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, pcc@google.com, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 16 Dec 2024 22:09:57 +0000, Mark Brown wrote: > > In commit 892f7237b3ff ("arm64: Delay initialisation of > cpuinfo_arm64::reg_{zcr,smcr}") we moved access to ZCR, SMCR and SMIDR > later in the boot process in order to ensure that we don't attempt to > interact with them if SVE or SME is disabled on the command line. > Unfortunately when initialising the boot CPU in init_cpu_features() we work > on a copy of the struct cpuinfo_arm64 for the boot CPU used only during > boot, not the percpu copy used by the sysfs code. The expectation of the > feature identification code was that the ID registers would be read in > __cpuinfo_store_cpu() and the values not modified by init_cpu_features(). > > The main reason for the original change was to avoid early accesses to > ZCR on practical systems that were seen shipping with SVE reported in ID > registers but traps enabled at EL3 and handled as fatal errors, SME was > rolled in due to the similarity with SVE. Since then we have removed the > early accesses to ZCR and SMCR in commits: > > abef0695f9665c3d ("arm64/sve: Remove ZCR pseudo register from cpufeature code") > 391208485c3ad50f ("arm64/sve: Remove SMCR pseudo register from cpufeature code") > > so only the SMIDR_EL1 part of the change remains. Since SMIDR_EL1 is > only trapped via FEAT_IDST and not the SME trap it is less likely to be > affected by similar issues, and the factors that lead to issues with SVE > are less likely to apply to SME. > > Since we have not yet seen practical SME systems that need to use a > command line override (and are only just beginning to see SME systems at > all) let's just remove the override and store SMIDR_EL1 along with all > the other ID register reads in __cpuinfo_store_cpu(). > > This issue wasn't apparent when testing on emulated platforms that do not > report values in SMIDR_EL1. > > Fixes: 892f7237b3ff ("arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}") > Signed-off-by: Mark Brown > Cc: stable@vger.kernel.org > --- > Changes in v2: > - Move the ID register read back to __cpuinfo_store_cpu(). > - Remove the command line option for SME ID register override. > - Link to v1: https://lore.kernel.org/r/20241214-arm64-fix-boot-cpu-smidr-v1-1-0745c40772dd@kernel.org My reading of the thread was that we don't need to kill the arm64.nosme option as SMIDR_EL1 wouldn't UNDEF, which is guaranteed if SME is implemented at all. What was needed in 6.0 is not there anymore, for all the reasons that Mark outlined and that you have pasted in the above commit message. The removal of the arm64.nosme option is still a possibility, but that's absolutely distinct from fixing the problem at hand. M. -- Without deviation from the norm, progress is not possible.