diff options
| author | Marc Zyngier <maz@kernel.org> | 2023-06-14 18:51:29 +0300 |
|---|---|---|
| committer | Oliver Upton <oliver.upton@linux.dev> | 2023-06-15 12:27:51 +0300 |
| commit | 1700f89cb99aae19e4f8ec38b1b59f3b7ae71b91 (patch) | |
| tree | 7a6f04c6ee0b24f9b2d01197c9049866d3666ec4 /arch/arm64/include/asm/el2_setup.h | |
| parent | ad744e8cb346743dd76425942910c7b75a782ed0 (diff) | |
| download | linux-1700f89cb99aae19e4f8ec38b1b59f3b7ae71b91.tar.xz | |
KVM: arm64: Fix hVHE init on CPUs where HCR_EL2.E2H is not RES1
On CPUs where E2H is RES1, we very quickly set the scene for
running EL2 with a VHE configuration, as we do not have any other
choice.
However, CPUs that conform to the current writing of the architecture
start with E2H=0, and only later upgrade with E2H=1. This is all
good, but nothing there is actually reconfiguring EL2 to be able
to correctly run the kernel at EL1. Huhuh...
The "obvious" solution is not to just reinitialise the timer
controls like we do, but to really intitialise *everything*
unconditionally.
This requires a bit of surgery, and is a good opportunity to
remove the macro that messes with SPSR_EL2 in init_el2_state.
With that, hVHE now works correctly on my trusted A55 machine!
Reported-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230614155129.2697388-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'arch/arm64/include/asm/el2_setup.h')
| -rw-r--r-- | arch/arm64/include/asm/el2_setup.h | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h index bba508ffa12d..5a353f94e9cd 100644 --- a/arch/arm64/include/asm/el2_setup.h +++ b/arch/arm64/include/asm/el2_setup.h @@ -205,7 +205,6 @@ __init_el2_nvhe_idregs __init_el2_cptr __init_el2_fgt - __init_el2_nvhe_prepare_eret .endm #ifndef __KVM_NVHE_HYPERVISOR__ |