summaryrefslogtreecommitdiffstats
path: root/virt
diff options
context:
space:
mode:
authorChristoffer Dall <christoffer.dall@linaro.org>2017-10-09 21:43:50 +0200
committerMarc Zyngier <marc.zyngier@arm.com>2018-03-19 10:53:10 +0000
commit8f17f5e4698ee5e42c827e8905cf39cf61c482c2 (patch)
treed151eaca18df587f527086602797eb2d9820f42e /virt
parent4464e210de9e80e38de59df052fe09ea2ff80b1b (diff)
downloadop-kernel-dev-8f17f5e4698ee5e42c827e8905cf39cf61c482c2.zip
op-kernel-dev-8f17f5e4698ee5e42c827e8905cf39cf61c482c2.tar.gz
KVM: arm64: Rework hyp_panic for VHE and non-VHE
VHE actually doesn't rely on clearing the VTTBR when returning to the host kernel, and that is the current key mechanism of hyp_panic to figure out how to attempt to return to a state good enough to print a panic statement. Therefore, we split the hyp_panic function into two functions, a VHE and a non-VHE, keeping the non-VHE version intact, but changing the VHE behavior. The vttbr_el2 check on VHE doesn't really make that much sense, because the only situation where we can get here on VHE is when the hypervisor assembly code actually called into hyp_panic, which only happens when VBAR_EL2 has been set to the KVM exception vectors. On VHE, we can always safely disable the traps and restore the host registers at this point, so we simply do that unconditionally and call into the panic function directly. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud