Messages in this thread Patch in this message | | | Subject | Re: [PATCH v4 2/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 | From | Dongli Zhang <> | Date | Wed, 2 Mar 2022 16:31:51 -0800 |
| |
Hi Boris,
On 3/2/22 4:20 PM, Boris Ostrovsky wrote: > > 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?
I just want to keep above sync with ....
> > > -boris > > >> if (!xen_feature(XENFEAT_hvm_safe_pvclock)) { >> pr_info("Xen doesn't support pvclock on HVM, disable pv timer"); >> + goto exit; >> + }
... here.
That is, I want the main logic of xen_hvm_init_time_ops() to run for at most once. Both of above two if statements will "go to exit".
Thank you very much!
Dongli Zhang
>> + >> + /* >> + * 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 >>
| |