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 85D7BC87FCA for ; Thu, 7 Aug 2025 08:11:25 +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=vwRlRZhd9HcW/VsgaBOUlQMMiB0MNOA95XUPY221qOM=; b=hSZvX3xc/8YzGc6jK7p1UO/JKZ WBBhYynfX02YS9X6xjRoFFYUo785pRc/jxncQidsrGHv2IGcSrK5ouR+QP8pm1yMmAZYBaM7xN3Xx l5qq77EeHNLmuPtRXT8D8CMQz4urfcRcrz5SBcFBvBREdQOGz7pOVvGtnfUEqAXqBJaq4JmI86h5s 9xcwon5vHxRuvd0PymQiH10Yvtd5TgOxaOZAMukcvv1T4NRCifLvxVpqA/ANi6rP3XgBeoJJLN8sZ dvRV8zC2W3IubOpxx5OQh3527Bkp1+RF7jQLG4UkvgCB1tcudr5zqt7rVJBGWoV4IX1d0WcwgzqCT HNriCoRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1ujviY-0000000HYnW-3G6x; Thu, 07 Aug 2025 08:11:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1ujvg1-0000000HYWp-2n7z for linux-arm-kernel@lists.infradead.org; Thu, 07 Aug 2025 08:08:42 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2F0185C5854; Thu, 7 Aug 2025 08:08:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8A7AC4CEEB; Thu, 7 Aug 2025 08:08:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754554120; bh=JCjp51GetSGxJBSbju8WEKymJlfBVo038kfQlZQ8YKE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WPEJYhOT6hOQ3atLqNwK4S8HXVgi4w8J7j2F+rhma3uNR3JIjJCtjRFxd70gNbGJh qxpqBnxdr7KSBkOONBN2mm+XMtXnam2/toGcNPLQwJqbTRZOXC4q+cAvro8QKyypYZ kRrERMgqt1y9V5uidKwIV3d5vceB4xSLbaot9RsIwGOqNFIYn+BHz7+CbsAxSubPDn X4jiUzrlGUZhiCyl74XOmtHLSy0pa/RzXIYIAtTiSTL8g4EBQVbx1zAfr+0xOqjbdG D6fSxMjZgCuDZeSz8tvlEAFEGvkTvvn71I+na2wEFyZr62JZoFlsegyvahmR30BCly ZIiy7dYVab2gQ== 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 1ujvfn-004mcZ-6S; Thu, 07 Aug 2025 09:08:27 +0100 Date: Thu, 07 Aug 2025 09:08:26 +0100 Message-ID: <864iuja70l.wl-maz@kernel.org> From: Marc Zyngier To: Palmer Dabbelt Cc: Catalin Marinas , Mark Rutland , Will Deacon , oliver.upton@linux.dev, james.morse@arm.com, cohuck@redhat.com, anshuman.khandual@arm.com, palmerdabbelt@meta.com, lpieralisi@kernel.org, kevin.brodsky@arm.com, scott@os.amperecomputing.com, broonie@kernel.org, james.clark@linaro.org, yeoreum.yun@arm.com, joey.gouly@arm.com, huangxiaojia2@huawei.com, yebin10@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: Expose CPUECTLR{,2}_EL1 via sysfs In-Reply-To: <20250806194812.46598-2-palmer@dabbelt.com> References: <20250806194812.46598-2-palmer@dabbelt.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) 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: palmer@dabbelt.com, catalin.marinas@arm.com, mark.rutland@arm.com, will@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, cohuck@redhat.com, anshuman.khandual@arm.com, palmerdabbelt@meta.com, lpieralisi@kernel.org, kevin.brodsky@arm.com, scott@os.amperecomputing.com, broonie@kernel.org, james.clark@linaro.org, yeoreum.yun@arm.com, joey.gouly@arm.com, huangxiaojia2@huawei.com, yebin10@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250807_010841_782878_5F827907 X-CRM114-Status: GOOD ( 24.68 ) 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, 06 Aug 2025 20:48:13 +0100, Palmer Dabbelt wrote: > > From: Palmer Dabbelt > > We've found that some of our workloads run faster when some of these > fields are set to non-default values on some of the systems we're trying > to run those workloads on. This allows us to set those values via > sysfs, so we can do workload/system-specific tuning. > > Signed-off-by: Palmer Dabbelt > --- > I've only really smoke tested this, but I figured I'd send it along because I'm > not sure if this is even a sane thing to be doing -- these extended control > registers have some wacky stuff in them, so maybe they're not exposed to > userspace on purpose. IIUC firmware can gate these writes, though, so it > should be possible for vendors to forbid the really scary values. That's really wrong. For a start, these encodings fall into the IMPDEF range. They won't exist on non-ARM implementations. Next, this will catch fire as a guest, either because the hypervisor will simply refuse to entertain letting it access registers that have no definition, or because the VM has been migrated from one implementation to another, and you have no idea this is doing on the new target. > > That said, we do see some performance improvements here on real workloads. So > we're hoping to roll some of this tuning work out more widely, but we also > don't want to adopt some internal interface. Thus it'd make our lives easier > if we could twiddle these bits in a standard way. Honestly, this is the sort of bring-up stuff that is better kept in your private sandbox, and doesn't really help in general. Thanks, M. -- Without deviation from the norm, progress is not possible.