Re: [PATCH v4 2/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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
>