From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 EC34C54CF4A; Wed, 9 Sep 2026 14:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788964178; cv=none; b=oPH0kcqLiMvDN+Lpp5rxBFmiZQ0wKB04QA7whJr8Z7GjTsOo4TQ0bmwTRY+wXSyRY3U94l8MVGK8ZDjthLZMVlKoZAcbSVaIpXSc9QCNbQin8aKMbtnkgogWpLwjne3SGK6g26v/vVt0EmRd1e9lO8jGik5OVSUNeJhThKaGCuo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788964178; c=relaxed/simple; bh=ZnKVmdJ0+txybHfevcWKArBIPP2qSbbM8PODeHjNXDk=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cZtSQ1nj0sihrTcDr4l9XwfNwMBIcP0S5KVEimkMHMYGWKHq7yWzo0S/Aw0o87ivlyRM0xxh31KWiawNqhS5yOytXLV/wWKzIjKPB0Abd27eB/vcvKXE1u3+nGoybi+cJ5mvaKUIx2eyaqsORfzxAsloV59eY0/ajKO7veBPdJk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mp3Gp/IS; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mp3Gp/IS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAAF51F00A3D; Wed, 9 Sep 2026 14:29:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788964176; bh=Se2xxe/a85TgX4HpduI7NMXMmiSfdyKReYm83RyVZEQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=mp3Gp/ISYu0vSbDYm62I7Ze2c9HBeBzaxBegbj7Cl4LJvu2Cx3R6+UlQwruZjt7+m nbe2ijWJ7BVOVYQIahZ2RFFG5QxULySNYH9SM7TRKwVIj5K4ueimVojMtsRljmJHs0 EjeFE/7bZQFanQIMoanZftO80yY+hcueMbxpeMYbPYzq97Ge8z3zcavsjAQt5jh7h7 qBkR6cKZiFwCGD4emGSIg3Fc2lbBn/IDdWNAAHpyT2tom3krouV/+GC1Omj1QX6K8W 32cchiGfWPaaU0DzqsB5qpgof+r6+e/bm2qjoUJTY1GM7f1hKNl4afbeUeVz9+L0rG uWTOrfen2DUfg== 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 1x4JIs-00000006jPD-2fdc; Wed, 09 Sep 2026 14:29:34 +0000 Date: Wed, 09 Sep 2026 15:29:29 +0100 Message-ID: <86zexq7b1y.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] KVM: arm64: Enable S1PIE for hVHE In-Reply-To: References: <20260908-kvm-arm64-nvhe-pie-v2-1-79e42d28cc08@kernel.org> <861pb24v45.wl-maz@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/30.1 (aarch64-unknown-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: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, 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 On Wed, 09 Sep 2026 13:17:33 +0100, Mark Brown wrote: > > > > +alternative_if ARM64_HAS_TCR2 > > > + ldr x1, [x0, #NVHE_INIT_TCR2_EL2] > > > + msr REG_TCR2_EL2, x1 > > > +alternative_else_nop_endif > > > S1PIE implies TCR2. Why the additional alternatives? > > That is true but TCR2 does not imply S1PIE, I wrote things this way so > that TCR2 is initialised even if we end up on a system where that is > present but S1PIE is not (or S1PIE is present but has been disabled by a > command line override). This is during startup so it seemed reasonable > to write things in a straightforward and easy to read fashion. Fair enough. > > TBH, I think this is completely going the wrong way. Why can't we > > write this as a discrete enumeration of the permission combination we > > support (all 3 of them), and map that to the correct index? > > I was deliberately following a similar pattern to that used for the host > kernel, intended to minimise code changes. I will rework so we have an > alternative path for S1PIE rather than trying to share. I think it is fine to keep the same indices as the kernel for permissions that map to something that can be expressed with direct permissions. But indirect permissions are not additive, and therefore shouldn't be constructed as such. They are also more expressive, and there will be a point where we will want to have other permissions that cannot be expressed by "emulating" direct permissions (Execute-Only springs to mind). At this stage, this is not churn. This is an investment. M. -- Without deviation from the norm, progress is not possible.