[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Dongli Zhang <dongli.zhang@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • Date: Tue, 12 Oct 2021 13:17:41 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cGE2TuyHkADiEiPmnl62LUEd6AbpUdfTJ7Tgho8OOFk=; b=YYYwRz/l4ZnemluR+0bW4JXdHxDNVIuZm08MNc6TRZzQSqK8YxhxWPhqhHLUbEUrD2+9ZeNRoVOznj0JIZ51BzIXlWSk5RUeph71NkgP72DvYZnxhTT4X5g8Kbf/InFrYqCL4yhyrhwi2taBAczRGaPxYBAUInx4soS337BziQ8kQ1eAc2Diwc84TSQ63m6+hxb33SyaKl5CVHcXZz+ay1ZcBlUWPngOwnFWPa1mW+DLeOAs+b7YRiFLpArG4eNH47Pw4wALD1ohvTTqSmF3rUhry1NlsWzelNE2LI4Fkc+4frWb0NzCmmxQo/YH++FEgNQ8R7EQNep8YHHrB+IaBQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a827fbOd0h84gzNT+TLPqvfFSJl2m9x3QTr7NmoAFLcfHEOCrI4BU8S9QBsO/wGetRqkUFwcU3rHJKCb5q0S7Di1b6FAfBaRLmSw4QEmML1hZ1cV/fP9gNZkwfzPtVKKA6ZlrqsEzLPhi0wGWN7PgShnUjOCF2VXGuzyJQPdYJasF0o2A5oPGzrvsqIvCpUs0VEHYNbsvjWPHHbPQmy6DIfkJ15nBHsOkvBTTLJIr4EDHfdao5cqgX8VOixfCWh/0hjrFNwEQuvp7ZFotf/QiqawYP5QGk7cSKQgujeO4et+eSQXdd84s1ck6Q5n26cpkpCIvwX1BfI/Qmlsvk7SOw==
  • Authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=oracle.com;
  • Cc: linux-kernel@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, jgross@xxxxxxxx, sstabellini@xxxxxxxxxx, tglx@xxxxxxxxxxxxx, mingo@xxxxxxxxxx, bp@xxxxxxxxx, hpa@xxxxxxxxx, andrew.cooper3@xxxxxxxxxx, george.dunlap@xxxxxxxxxx, iwj@xxxxxxxxxxxxxx, jbeulich@xxxxxxxx, julien@xxxxxxx, wl@xxxxxxx, joe.jin@xxxxxxxxxx
  • Delivery-date: Tue, 12 Oct 2021 17:19:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


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();



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.