Messages in this thread | | | Date | Wed, 2 Mar 2022 19:20:38 -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: > void __init xen_hvm_init_time_ops(void) > { > + static bool hvm_time_initialized; > + > + if (hvm_time_initialized) > + return; > + > /* > * vector callback is needed otherwise we cannot receive interrupts > * on cpu > 0 and at this point we don't know how many cpus are > * available. > */ > if (!xen_have_vector_callback) > - return; > + goto exit;
Why not just return? Do we expect the value of xen_have_vector_callback to change?
-boris
> > if (!xen_feature(XENFEAT_hvm_safe_pvclock)) { > pr_info("Xen doesn't support pvclock on HVM, disable pv timer"); > + goto exit; > + } > + > + /* > + * Only MAX_VIRT_CPUS 'vcpu_info' are embedded inside 'shared_info'. > + * The __this_cpu_read(xen_vcpu) is still NULL when Xen HVM guest > + * boots on vcpu >= MAX_VIRT_CPUS (e.g., kexec), To access > + * __this_cpu_read(xen_vcpu) via xen_clocksource_read() will panic. > + * > + * The xen_hvm_init_time_ops() should be called again later after > + * __this_cpu_read(xen_vcpu) is available. > + */ > + if (!__this_cpu_read(xen_vcpu)) { > + pr_info("Delay xen_init_time_common() as kernel is running on vcpu=%d\n", > + xen_vcpu_nr(0)); > return; > } > > @@ -577,6 +597,9 @@ void __init xen_hvm_init_time_ops(void) > x86_cpuinit.setup_percpu_clockev = xen_hvm_setup_cpu_clockevents; > > x86_platform.set_wallclock = xen_set_wallclock; > + > +exit: > + hvm_time_initialized = true; > } > #endif >
| |