summaryrefslogtreecommitdiffstats
path: root/arch/x86/xen/trace.c
diff options
context:
space:
mode:
authorDexuan Cui <decui@microsoft.com>2020-12-21 22:55:41 -0800
committerWei Liu <wei.liu@kernel.org>2021-01-05 17:52:04 +0000
commitdfe94d4086e40e92b1926bddcefa629b791e9b28 (patch)
treefb6fe7ef7968b71ca528444f532ecb757a358432 /arch/x86/xen/trace.c
parente71ba9452f0b5b2e8dc8aa5445198cd9214a6a62 (diff)
downloadlinux-dfe94d4086e40e92b1926bddcefa629b791e9b28.tar.bz2
x86/hyperv: Fix kexec panic/hang issues
Currently the kexec kernel can panic or hang due to 2 causes: 1) hv_cpu_die() is not called upon kexec, so the hypervisor corrupts the old VP Assist Pages when the kexec kernel runs. The same issue is fixed for hibernation in commit 421f090c819d ("x86/hyperv: Suspend/resume the VP assist page for hibernation"). Now fix it for kexec. 2) hyperv_cleanup() is called too early. In the kexec path, the other CPUs are stopped in hv_machine_shutdown() -> native_machine_shutdown(), so between hv_kexec_handler() and native_machine_shutdown(), the other CPUs can still try to access the hypercall page and cause panic. The workaround "hv_hypercall_pg = NULL;" in hyperv_cleanup() is unreliabe. Move hyperv_cleanup() to a better place. Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20201222065541.24312-1-decui@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
Diffstat (limited to 'arch/x86/xen/trace.c')
0 files changed, 0 insertions, 0 deletions