Messages in this thread | | | Date | Tue, 12 Oct 2021 13:17:41 -0400 | Subject | Re: [PATCH linux 1/2] xen: delay xen_hvm_init_time_ops() if kdump is boot on vcpu>=32 | From | Boris Ostrovsky <> |
| |
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(); >
| |