| Message ID | 20230526143348.4072074-6-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: arm64: Allow using VHE in the nVHE hypervisor | expand |
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. Same nit applies to the kaslr case as well. > + ubfx x2, x2, #ARM64_SW_FEATURE_OVERRIDE_HVHE, #4 > + cbz x2, 2f > > 1: mov_q x0, HVC_STUB_ERR > eret > -- > 2.34.1 >
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.
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@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. 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.
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 + ubfx x2, x2, #ARM64_SW_FEATURE_OVERRIDE_HVHE, #4 + cbz x2, 2f 1: mov_q x0, HVC_STUB_ERR eret
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(-)