[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 Mar 2022 19:20:38 -0500
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Dongli Zhang <dongli.zhang@...cle.com>,
xen-devel@...ts.xenproject.org, x86@...nel.org
Cc: linux-kernel@...r.kernel.org, jgross@...e.com,
sstabellini@...nel.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, joe.jin@...cle.com
Subject: Re: [PATCH v4 2/2] xen: delay xen_hvm_init_time_ops() if kdump is
boot on vcpu>=32
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
>
Powered by blists - more mailing lists