Re: [PATCH v2] KVM: arm64: Enable S1PIE for hVHE

[Marc Zyngier <maz@kernel.org>]

On Wed, 09 Sep 2026 13:17:33 +0100,
Mark Brown <broonie@kernel.org> 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.