Messages in this thread | | | Date | Fri, 11 Mar 2022 09:19:46 -0500 | Subject | Re: [PATCH v4 2/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 | From | Boris Ostrovsky <> |
| |
On 3/2/22 11:40 AM, Dongli Zhang wrote: > 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 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. > > Cc: Joe Jin <joe.jin@oracle.com> > Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Applied to for-linus-5.18 (with return path adjusted)
| |