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

[Oliver Upton]

On Thu, Jun 01, 2023 at 01:48:42PM +0100, Marc Zyngier wrote:
> On Thu, 01 Jun 2023 08:32:40 +0100,
> Oliver Upton <oliver.upton at 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 at 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.

Fair enough. Coming at it from the other angle (i.e. ignoring the ID
reg side) it is only slightly weird, but does not really matter. I'm
fine with this as-is.

-- 
Thanks,
Oliver