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 34C072F5A1D; Wed, 22 Oct 2025 08:44:38 +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=1761122679; cv=none; b=WUhXV//MLdEgZHn0XLXBRkZbqVZ1WoI2d3eYjWUwYTjEORi24jGerhZt81uqJs37saezrcVR44MZ0O4oz2BkskWN2cdKVK96lLl4fJCHrZ4CaCi+WzdeRzRuF6TX4tEclcAiP1Wea1N1Pk9KDtZEJXoNdj28jqgDjGTHX2KaHpE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761122679; c=relaxed/simple; bh=jbN+CoRUpR8I4L1UUX+XaVKaNlIDiMfIKInpFU2+ytw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=qByyCFAWdC7Y/WP11aiAfnL1iyvjjBGeBN7YvRP2+J1e/BIdeE9JXBQfpdzvmnjp0t5kWrjqQa6VAssrtL1Y7ZvpLH2+/O8JElWXKx/Au+f7n/gwTY6pyj6FxYn8AHwCHe/xYtPSPXQrE29++1u2es9mF0RIzQ5v1MytlztSXQg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nF4ve3k3; 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="nF4ve3k3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1683C4CEE7; Wed, 22 Oct 2025 08:44:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761122678; bh=jbN+CoRUpR8I4L1UUX+XaVKaNlIDiMfIKInpFU2+ytw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nF4ve3k3M7eA7mCBacJC4eLH4VVlErlCmFl/H8dDw9mGDnKmyY/KcDahvFn1lRBUv fUxvm9rCOF0djLvPmdw0ox4keTjao+QL8n1OZeTN+5BPIe5VvM6F/+N84QATAQxEAD /vM0tZ6oGwOsrPT+fENEuUwywwncl3ujmK2Up+exwkOI8Qm1o/Ny617xyDzaRL099l DypuJ7u6vlmRCbMFcd1EZdK/7poBZmeDIspnlDej3QGeTUkjqLnkgj0t3JM6QXahIY GNszmZLl9Ag5xESeAl1CzD3mbCksBrPEWEL/Tg9a3bqeILRXIATYt3ur9ap/P1mDJB Am2N7+2cWpIzQ== 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 1vBUSS-0000000G7OH-0TGl; Wed, 22 Oct 2025 08:44:36 +0000 Date: Wed, 22 Oct 2025 09:44:35 +0100 Message-ID: <865xc7wcjw.wl-maz@kernel.org> From: Marc Zyngier To: "Liao, Chang" Cc: , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH] arm64: Add kernel parameter to disable trap EL0 accesses to IMPDEF regs In-Reply-To: <0e885995-c85e-4f0f-b0e6-edac9928d854@huawei.com> References: <20251021115428.557084-1-liaochang1@huawei.com> <86ecqwwig3.wl-maz@kernel.org> <0e885995-c85e-4f0f-b0e6-edac9928d854@huawei.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) Precedence: bulk X-Mailing-List: linux-doc@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: liaochang1@huawei.com, corbet@lwn.net, catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, paulmck@kernel.org, pawan.kumar.gupta@linux.intel.com, mingo@kernel.org, bp@alien8.de, kees@kernel.org, arnd@arndb.de, fvdl@google.com, broonie@kernel.org, oliver.upton@linux.dev, yeoreum.yun@arm.com, yangyicong@hisilicon.com, james.morse@arm.com, ardb@kernel.org, hardevsinh.palaniya@siliconsignals.io, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 22 Oct 2025 03:37:04 +0100, "Liao, Chang" wrote: >=20 > Hi Marc, >=20 > =E5=9C=A8 2025/10/21 20:25, Marc Zyngier =E5=86=99=E9=81=93: > > On Tue, 21 Oct 2025 12:54:28 +0100, > > Liao Chang wrote: > >> > >> Add kernel parameter to allow system-wide EL0 access to IMPDEF system > >> regregisters and instructions without trapping to EL1/EL2. Since trap > >> overhead will compromises benefits, and it's even worse in > >> virtualization on CPU where certain IMPDEF registers and instructions > >> are designed for EL0 performance use. > >=20 > > Since you mention virtualisation, I want to be clear: there is no way > > I will consider anything like this for KVM. KVM will always trap and > > UNDEF such register accesses, no matter where they come from (EL0 or > > EL1). > >=20 > > Allowing such registers to be accessed from within a guest would make > > it impossible to context-switch or save/restore the guest correctly. > >=20 > > You can of course do what you want in your downstream kernel or your > > own hypervisor, but I wanted to set the expectations on the upstream > > side. >=20 > Does it make sense to allow EL0 access IMPDEF without trapping for some > special vendor CPUID, instead of forbidding it as the default setting on > the upstream code? Let me answer your question with my own questions: How can supervisory software (kernel or hypervisor) save and restore state that it doesn't know about? How can it ensure isolation of state if there are unspecified registers that can change unspecified things behind its back? You'd need to add CPU-specific code to the kernel to make that work, and SW written to make use of these functionalities wouldn't work anywhere else. So if you end-up with a custom userspace, why should upstream care? There is zero benefit to the ecosystem. Thanks, M. --=20 Without deviation from the norm, progress is not possible.