@@ -216,7 +216,6 @@ static void __init xen_hvm_guest_init(void)
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
xen_unplug_emulated_devices();
x86_init.irqs.intr_init = xen_init_IRQ;
- xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
#ifdef CONFIG_KEXEC_CORE
@@ -19,6 +19,23 @@ static void __init xen_hvm_smp_prepare_boot_cpu(void)
*/
xen_vcpu_setup(0);
+ /*
+ * xen_hvm_init_time_ops() used to be called at very early stage
+ * by xen_hvm_guest_init(). While only MAX_VIRT_CPUS 'vcpu_info'
+ * are embedded inside 'shared_info', the VM would use them until
+ * xen_vcpu_setup() is used to allocate/relocate them at arbitrary
+ * address.
+ *
+ * However, when Xen HVM guest boots on vcpu >= MAX_VIRT_CPUS
+ * (e.g., kexec kernel), per_cpu(xen_vcpu, cpu) is NULL at early
+ * stage. To access per_cpu(xen_vcpu, cpu) via
+ * xen_clocksource_read() would panic the kernel.
+ *
+ * Therefore we always delay xen_hvm_init_time_ops() to
+ * xen_hvm_smp_prepare_boot_cpu() to avoid the panic.
+ */
+ xen_hvm_init_time_ops();
+
/*
* The alternative logic (which patches the unlock/lock) runs before
* the smp bootup up code is activated. Hence we need to set this up
The sched_clock() can be used very early since commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition, with commit 38669ba205d1 ("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 always delays xen_hvm_init_time_ops() to later in xen_hvm_smp_prepare_boot_cpu() after the 'vcpu_info' for boot vcpu is registered. 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" Unfortunately, the 'soft_reset' (kexec) does not work with mainline xen version so that I can test this patch only with HVM guest on old xen hypervisor where 'soft_reset' is working. The bugfix for PVM is not implemented due to the lack of testing environment. Cc: Joe Jin <joe.jin@oracle.com> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> --- Changed since v1: - Add commit message to explain why xen_hvm_init_time_ops() is delayed for any vcpus. (Suggested by Boris Ostrovsky) - Add a comment in xen_hvm_smp_prepare_boot_cpu() referencing the related code in xen_hvm_guest_init(). (suggested by Juergen Gross) Changed since v2: - Delay for all VCPUs. (Suggested by Boris Ostrovsky) - Add commit message that why PVM is not supported by this patch - Test if kexec/kdump works with mainline xen (HVM and PVM) arch/x86/xen/enlighten_hvm.c | 1 - arch/x86/xen/smp_hvm.c | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-)