[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] cpu/hotplug: Allow the CPU in CPU_UP_PREPARE state to be brought up again.
- To: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
- From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Date: Mon, 6 Dec 2021 08:39:53 -0500
- 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=FTSWx2zpYLbbOuaN9PiB/j55Kh0iAWfbOK3m5GF2lPY=; b=EIIg6if26uQ2+5Kw5v/KM7l+rvI5grtQGaSbIv+WYNaALJtKfZvumbCW7Q/10UTiUUPA4uAoAggiEFGau3cdkH1HORj7doApyy5pmLji/+Q6POp8icChc75oUhD9T00clLy4c61Dh/tw7hgAG1QoKRDEgPmqVgwPSwRE5htokLKHbH8Z1pd0K/foLfOEoMupgh+dvvzpkUTKuTxigkTdAM2ajhvx66eDoBGSEoKJZ2oFedooIevXeiQP6fH0r2Luw34ja147sMwb20tdjBo9VScaAs/PUttZthNO+WNNTUPkPDA8Ph+WI6GlVIM+z7CwS3wIE1p7EM66K3rC+5RCYw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IC6kIJOjoUzzLOvT73dD+gGpwmn8EPUA1kAIbjgbv70YiQvkhMTC7IzTooMZ/eT75RF01lBewR1f3kG/k/v7/YC3e3uvia6HsXpyJSqL5lLN8AKn46o44L6YTV5TpgawQm4/0Ha5O3LdnQmZKP0zGvUSPsSc7hC8kCRi1mnb7lj0smDc2qoxzTkqNwvCglxkZXeI8SarDTy7XDOZd1TPrV/tJR/zVSCinjNT7pdfiHKbb7yD5PJONoZ4WnJPULL2AOvCjn60m8HExtLJpS4C0It4D5VXlyfC2Qffj1dx2ZdzF2HYBpokUnZBzh1WlKtM5RLl4h494ougjMk5sbDkzA==
- Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>, "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" <longpeng2@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, "Gonglei (Arei)" <arei.gonglei@xxxxxxxxxx>, x86@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Valentin Schneider <valentin.schneider@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>
- Delivery-date: Mon, 06 Dec 2021 13:40:59 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 12/6/21 6:25 AM, Sebastian Andrzej Siewior wrote:
On 2021-11-24 21:17:34 [-0500], Boris Ostrovsky wrote:
On 11/24/21 5:54 PM, Thomas Gleixner wrote:
Any comment from XEN folks?
If memory allocation in cpu_initialize_context() fails we will not be
able to bring up the VCPU because xen_cpu_initialized_map bit at the
top of that routine will already have been set. We will BUG in
xen_pv_cpu_up() on second (presumably successful) attempt because
nothing for that VCPU would be initialized. This can in principle be
fixed by moving allocation to the top of the routine and freeing
context if the bit in the bitmap is already set.
Having said that, allocation really should not fail: for PV guests we
first bring max number of VCPUs up and then offline them down to
however many need to run. I think if we fail allocation during boot we
are going to have a really bad day anyway.
So can we keep the patch as-is or are some changes needed?
I think for the sake of completeness we could add
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 6a8f3b53ab83..86368fcef466 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -277,8 +277,11 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
return 0;
ctxt = kzalloc(sizeof(*ctxt), GFP_KERNEL);
- if (ctxt == NULL)
+ if (ctxt == NULL) {
+ cpumask_clear_cpu(cpu, xen_cpu_initialized_map);
+ cpumask_clear_cpu(cpu, cpu_callout_mask);
return -ENOMEM;
+ }
gdt = get_cpu_gdt_rw(cpu);
-boris
|
