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 711E4CCD1BB for ; Wed, 22 Oct 2025 15:02:26 +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-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=h5NTlC4IxBrqx0ARksxlgPf3/sqZgHI5JZczrMkgS3k=; b=V+Hj6blUxK6Elo0v+etbZBUvup 7l42xG7G/7XxR3b5MDfSE5XyMj/etkVbihSfu6xv7aM6EwG6vkb8Wqg5TY6womLIqzc9NgwmZt9ve rUC2SUWv6qsq1qG6yXSgjTcRSMaIoHeLibwMZSzj8Jbo20Om1i49D7yidSJ0AMUQya4o15aKdG5b5 o92lKBo63bBbmBplhq+Da26f+DN1ztFjIoRPBRyx+1Xhpg6AI4rMpuZhc8vQEUdG2iLSIYBtvZcfh B/uXlfxptL23Vw/sbqnCXGlrbzX/rnX68NYc1hEdlfwxPie+qQXA9CkFwRwSGVmAX6XUE9l1P2Yxm LCcBiBNg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vBaM0-00000003JnM-1arm; Wed, 22 Oct 2025 15:02:20 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vBaLy-00000003JmQ-42d8 for linux-arm-kernel@lists.infradead.org; Wed, 22 Oct 2025 15:02:19 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5F5A563C75; Wed, 22 Oct 2025 15:02:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05665C4CEE7; Wed, 22 Oct 2025 15:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761145338; bh=k3fJI9mIBTsdVJCA44WRE8AYW3GDEJaeAfXMOod7lh0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KJmSQyItxkvT/XA9gWGgFrfwAKV9G/owa2fPY1an14KOo3/4HYjA0PTE4WlNKY133 k9Ygk3d45EI/bemx7jbH/QYMmZDGnS5aIs0YVyfkQO2ySoCcG+JBNLw9aMUkLKyASS 1qy6aXOCNLtU/UmKhI+ypQ3UZGrSaKtC8TVByeX04pCsqyXQycMV2DCEXUzndJJK4j wktrpVjGUQUaCzXgqWrJnjBdPZhXIK16YC5+gzDp1w8dtOIECbX0QFKR0QYf2gVYGs Jq68LlQhDxhG9rxH1IUQRhHaIzsDBRei63puPkM/6JUHtoJrS9VWnAKnC8OfJ4Hz5R U4Va0WnxCraNg== 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 1vBaLw-0000000GEVa-0JQv; Wed, 22 Oct 2025 15:02:16 +0000 Date: Wed, 22 Oct 2025 16:02:15 +0100 Message-ID: <861pmvvv2g.wl-maz@kernel.org> From: Marc Zyngier To: Marek Vasut Cc: Marek Vasut , linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Geert Uytterhoeven , Ryan Roberts , Will Deacon , Yicong Yang , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN In-Reply-To: <07391913-aab6-4d92-b75f-278506f51397@mailbox.org> References: <20251022133621.178546-1-marek.vasut+renesas@mailbox.org> <86347bvx0f.wl-maz@kernel.org> <07391913-aab6-4d92-b75f-278506f51397@mailbox.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/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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: marek.vasut@mailbox.org, marek.vasut+renesas@mailbox.org, linux-arm-kernel@lists.infradead.org, anshuman.khandual@arm.com, catalin.marinas@arm.com, geert+renesas@glider.be, ryan.roberts@arm.com, will@kernel.org, yangyicong@hisilicon.com, linux-renesas-soc@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 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 Wed, 22 Oct 2025 15:33:38 +0100, Marek Vasut wrote: > > On 10/22/25 4:20 PM, Marc Zyngier wrote: > > On Wed, 22 Oct 2025 14:35:28 +0100, > > Marek Vasut wrote: > >> > >> The AMU configuration register access may fault and prevent successful > >> kernel boot. This can occur for example in case the firmware does not > >> allow AMU counter access from EL1. Guard the AMU configuration register > >> access with ARM64_HAS_AMU_EXTN to prevent this fault if ARM64_HAS_AMU_EXTN > >> Kconfig option is explicitly disabled. Other interaction with the AMU is > >> already guarded by similar ifdeffery. > >> > >> Fixes: 87a1f063464a ("arm64: trap to EL1 accesses to AMU counters from EL0") > >> Signed-off-by: Marek Vasut > >> --- > >> Cc: Anshuman Khandual > >> Cc: Catalin Marinas > >> Cc: Geert Uytterhoeven > >> Cc: Marc Zyngier > >> Cc: Ryan Roberts > >> Cc: Will Deacon > >> Cc: Yicong Yang > >> Cc: linux-arm-kernel@lists.infradead.org > >> Cc: linux-renesas-soc@vger.kernel.org > >> --- > >> arch/arm64/mm/proc.S | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S > >> index 86818511962b6..123538ffeda6b 100644 > >> --- a/arch/arm64/mm/proc.S > >> +++ b/arch/arm64/mm/proc.S > >> @@ -145,7 +145,9 @@ SYM_FUNC_START(cpu_do_resume) > >> ubfx x11, x11, #1, #1 > >> msr oslar_el1, x11 > >> reset_pmuserenr_el0 x0 // Disable PMU access from EL0 > >> +alternative_if ARM64_HAS_AMU_EXTN > >> reset_amuserenr_el0 x0 // Disable AMU access from EL0 > >> +alternative_else_nop_endif > > > > Why? > > > > We ensure that the AMU is available in the macro itself by checking > > for ID_AA64PFR0_EL1.AMU. If the AMu isn't present on this CPU, we skip > > the offending sysreg access. This is similar to what we do for the > > PMU. > > > > Does your HW advertise an AMU, but doesn't actually have one? > > The hardware does have AMU, but it is currently blocked in old TFA > version and access to this AMU register here causes a fault. That's > why I have to disable ARM64_HAS_AMU_EXTN until the TFA is updated and > the AMU access is made available on this hardware. But even if I do > disable ARM64_HAS_AMU_EXTN=n , I get a fault. Well, I would tend to say that you are trying to update the wrong piece of SW here. Crashing kernels should be a good incentive for the board manufacturer to update their firmware pronto, specially when we are talking of code that has been in the tree for over 5 years... > This patch is mainly meant to prevent a surprise in case someone does > set ARM64_HAS_AMU_EXTN=n , and the system still faults on AMU register > access. But that doesn't really fix anything if you have a buggy firmware, because you can't tell which CPUs have been correctly configured, and which have not. I also don't really get why this hack works for you, because the feature will be set as soon as one CPU advertises the feature. In any case, this sort of terminally broken stuff should be handled as an IDreg override, for which we have a whole infrastructure already. There are countless examples in the tree already for similar purposes. Thanks, M. -- Without deviation from the norm, progress is not possible.