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 0EB4D32E6A6; Tue, 21 Oct 2025 12:25:03 +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=1761049504; cv=none; b=ARcYTKLnGQCutpwzBMqP9l1Fc1JjI62rOZFRY1TaMzw4Da3BfHYdWS6mMQCChPMby+XFtSShi5xd44CN8jWLWWBe9qScghi2swf/ZX4OoMYXwohyvNswBE2vRmsvZR4StUUTqhInN26+Mz7Y0j02ZPhJYi+kPdchBdruBuZS5S4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761049504; c=relaxed/simple; bh=QAp0WH1C/zbfZAC6WrcLNYkAgwamHfqX68wiGHk2Ts8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=lSoPFLLeA3C2Jrc8PL0PzAtreVyIR01l2zaP7A8RA12QQBFI2W658D3qnWJJuZur/YuyzxaXuupMx+sdyNfNUOayNp89fiSfvmB1DeSzrz3mTeZt7rXjmRSGi/i2sA7RrLnSZ/K5PiBxzTXEb75AVJduod18ub8QpPPThCdcj3s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JXpsIlZz; 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="JXpsIlZz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F8D7C4CEF5; Tue, 21 Oct 2025 12:25:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761049503; bh=QAp0WH1C/zbfZAC6WrcLNYkAgwamHfqX68wiGHk2Ts8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JXpsIlZz/zrd/nzfTJJ5XNltOcWIGmTh8FTDJ3uXwKmN9f58zgtXBBZc5sJOJ9iiw lD4TDc1sDlOtT4mzVIYYdsYL+pkl2h+QwjcqhF7Y6x/xgAaLbz2RjYlIG5XRhSrSgU 4GjTbBa6neRY7T3Cv2pQXbY7LJm3e5zI1NOoqYkhN3NIS57eTrkuyLejkGCOc7VAy9 ez5k+o6N+HgrU8IMjE3GG+n27TgpCXrdL1OdrcaioJ9T3l3NsUci3+WwEWXEefF4C6 RibxOQYv0qMgIdI7tNXdjtE173keuMegx9bQX8vQIYaA/lxdNQGPpNaf6K7AwdboAV Tgoke2Q5++u+w== 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 1vBBQC-0000000FpwD-3dby; Tue, 21 Oct 2025 12:25:00 +0000 Date: Tue, 21 Oct 2025 13:25:00 +0100 Message-ID: <86ecqwwig3.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: <20251021115428.557084-1-liaochang1@huawei.com> References: <20251021115428.557084-1-liaochang1@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=US-ASCII 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 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. 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). Allowing such registers to be accessed from within a guest would make it impossible to context-switch or save/restore the guest correctly. 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. M. -- Without deviation from the norm, progress is not possible.