lkml.org 
[lkml]   [2021]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH linux 1/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32
From

On 10/12/21 3:24 AM, Dongli Zhang wrote:
> The sched_clock() can be used very early since upstream
> commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
> with upstream commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock
> time from 0"), kdump kernel in Xen HVM guest may panic at very early stage
> when accessing &__this_cpu_read(xen_vcpu)->time as in below:


Please drop "upstream". It's always upstream here.


> +
> + /*
> + * Only MAX_VIRT_CPUS 'vcpu_info' are embedded inside 'shared_info'
> + * and the VM would use them until xen_vcpu_setup() is used to
> + * allocate/relocate them at arbitrary address.
> + *
> + * However, when Xen HVM guest panic on vcpu >= MAX_VIRT_CPUS,
> + * per_cpu(xen_vcpu, cpu) is still NULL at this stage. To access
> + * per_cpu(xen_vcpu, cpu) via xen_clocksource_read() would panic.
> + *
> + * Therefore we delay xen_hvm_init_time_ops() to
> + * xen_hvm_smp_prepare_boot_cpu() when boot vcpu is >= MAX_VIRT_CPUS.
> + */
> + if (xen_vcpu_nr(0) >= MAX_VIRT_CPUS)


What about always deferring this when panicing? Would that work?


Deciding whether to defer based on cpu number feels a bit awkward.


-boris


> + pr_info("Delay xen_hvm_init_time_ops() as kernel is running on vcpu=%d\n",
> + xen_vcpu_nr(0));
> + else
> + xen_hvm_init_time_ops();
> +
> xen_hvm_init_mmu_ops();
>

\
 
 \ /
  Last update: 2021-10-12 19:19    [W:0.074 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site