Re: [PATCH v2 05/17] arm64: Don't enable VHE for the kernel if OVERRIDE_HVHE is set

From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Quentin Perret <qperret@google.com>,
	Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH v2 05/17] arm64: Don't enable VHE for the kernel if OVERRIDE_HVHE is set
Date: Thu, 01 Jun 2023 13:48:42 +0100	[thread overview]
Message-ID: <87bkhzpcut.wl-maz@kernel.org> (raw)
In-Reply-To: <ZHhJmJU/m//uTI9n@linux.dev>

On Thu, 01 Jun 2023 08:32:40 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Fri, May 26, 2023 at 03:33:36PM +0100, Marc Zyngier wrote:
> > If the OVERRIDE_HVHE SW override is set (as a precursor of
> > the KVM_HVHE capability), do not enable VHE for the kernel
> > and drop to EL1 as if VHE was either disabled or unavailable.
> > 
> > Further changes will enable VHE at EL2 only, with the kernel
> > still running at EL1.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/kernel/hyp-stub.S | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
> > index 9439240c3fcf..5c71e1019545 100644
> > --- a/arch/arm64/kernel/hyp-stub.S
> > +++ b/arch/arm64/kernel/hyp-stub.S
> > @@ -82,7 +82,15 @@ SYM_CODE_START_LOCAL(__finalise_el2)
> >  	tbnz	x1, #0, 1f
> >  
> >  	// Needs to be VHE capable, obviously
> > -	check_override id_aa64mmfr1 ID_AA64MMFR1_EL1_VH_SHIFT 2f 1f x1 x2
> > +	check_override id_aa64mmfr1 ID_AA64MMFR1_EL1_VH_SHIFT 0f 1f x1 x2
> > +
> > +0:	// Check whether we only want the hypervisor to run VHE, not the kernel
> > +	adr_l	x1, arm64_sw_feature_override
> > +	ldr	x2, [x1, FTR_OVR_VAL_OFFSET]
> > +	ldr	x1, [x1, FTR_OVR_MASK_OFFSET]
> > +	and	x2, x2, x1
> 
> nit: is applying the mask even necessary? I get it in the context of an
> overlay on top of an ID register, but the software features are more of
> a synthetic ID register in their own right.

I guess I don't have a good reason just yet, but on the other hand it
makes things predictable if the override code refuses the override for
some reason other than not being VHE-capable (mask becomes 0 and val
becomes 0xf).

Overall, I feel that this code is too hard to follow to do anything
different from the "standard" case.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel