Re: [PATCH v4 2/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32
From: Dongli Zhang
Date: Wed Mar 02 2022 - 19:33:38 EST
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
>>