Dongli Zhang a2a0e04f64 xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 ... [ Upstream commit eed05744322da07dd7e419432dcedf3c2e017179 ] The sched_clock() can be used very early since commit 857baa87b6 ("sched/clock: Enable sched clock early"). In addition, with commit 38669ba205 ("x86/xen/time: Output xen sched_clock time from 0"), kdump kernel in Xen HVM guest may panic at very early stage when accessing &__this_cpu_read(xen_vcpu)->time as in below: setup_arch() -> init_hypervisor_platform() -> x86_init.hyper.init_platform = xen_hvm_guest_init() -> xen_hvm_init_time_ops() -> xen_clocksource_read() -> src = &__this_cpu_read(xen_vcpu)->time; This is because Xen HVM supports at most MAX_VIRT_CPUS=32 'vcpu_info' embedded inside 'shared_info' during early stage until xen_vcpu_setup() is used to allocate/relocate 'vcpu_info' for boot cpu at arbitrary address. However, when Xen HVM guest panic on vcpu >= 32, since xen_vcpu_info_reset(0) would set per_cpu(xen_vcpu, cpu) = NULL when vcpu >= 32, xen_clocksource_read() on vcpu >= 32 would panic. This patch calls xen_hvm_init_time_ops() again later in xen_hvm_smp_prepare_boot_cpu() after the 'vcpu_info' for boot vcpu is registered when the boot vcpu is >= 32. This issue can be reproduced on purpose via below command at the guest side when kdump/kexec is enabled: "taskset -c 33 echo c > /proc/sysrq-trigger" The bugfix for PVM is not implemented due to the lack of testing environment. [boris: xen_hvm_init_time_ops() returns on errors instead of jumping to end] Cc: Joe Jin <joe.jin@oracle.com> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20220302164032.14569-3-dongli.zhang@oracle.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>		2022-04-13 21:01:01 +02:00
..
Kconfig	…
Makefile	…
apic.c	…
debugfs.c	…
debugfs.h	…
efi.c	…
enlighten.c	xen/x86: prevent PVH type from getting clobbered	2021-10-27 09:56:46 +02:00
enlighten_hvm.c	x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery	2021-01-27 11:55:01 +01:00
enlighten_pv.c	x86/Xen: streamline (and fix) PV CPU enumeration	2022-02-23 12:01:00 +01:00
enlighten_pvh.c	treewide: Convert macro and uses of __section(foo) to __section("foo")	2020-10-25 14:51:49 -07:00
grant-table.c	x86/xen: open code alloc_vm_area in arch_gnttab_valloc	2020-10-18 09:27:10 -07:00
irq.c	…
mmu.c	…
mmu.h	…
mmu_hvm.c	…
mmu_pv.c	xen: branch for v5.10-rc1	2020-10-14 10:34:45 -07:00
multicalls.c	…
multicalls.h	…
p2m.c	xen: fix setting of max_pfn in shared_info	2021-09-18 13:40:06 +02:00
pci-swiotlb-xen.c	dma-mapping: split <linux/dma-mapping.h>	2020-10-06 07:07:03 +02:00
platform-pci-unplug.c	…
pmu.c	xen: fix is_xen_pmu()	2022-04-08 14:40:29 +02:00
pmu.h	xen: fix is_xen_pmu()	2022-04-08 14:40:29 +02:00
setup.c	Revert "xen: fix p2m size in dom0 for disabled memory hotplug case"	2021-03-30 14:32:08 +02:00
smp.c	xen/events: only register debug interrupt for 2-level events	2020-10-23 05:41:25 -05:00
smp.h	…
smp_hvm.c	xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32	2022-04-13 21:01:01 +02:00
smp_pv.c	xen: fix is_xen_pmu()	2022-04-08 14:40:29 +02:00
spinlock.c	x86/xen: don't unbind uninitialized lock_kicker_irq	2020-11-09 07:43:45 -06:00
suspend.c	…
suspend_hvm.c	…
suspend_pv.c	…
time.c	xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32	2022-04-13 21:01:01 +02:00
trace.c	…
vga.c	…
xen-asm.S	x86/xen: Add xenpv_restore_regs_and_return_to_usermode()	2021-12-08 09:03:27 +01:00
xen-head.S	…
xen-ops.h	xen/events: only register debug interrupt for 2-level events	2020-10-23 05:41:25 -05:00