On Thu, 01 Jun 2023 08:32:40 +0100, Oliver Upton <oliver.upton@xxxxxxxxx> 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@xxxxxxxxxx> > > --- > > 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.
