Message ID | 20231225080524.4240-1-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-10945-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp284152dyb; Mon, 25 Dec 2023 00:07:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IHTHqv7kZFpk7O+XN5bZdxIQEdilRkhIO9wUjS2paSwznbwjd7LlJNWXIIovFNQE+qRr5di X-Received: by 2002:aa7:d287:0:b0:553:84c0:1797 with SMTP id w7-20020aa7d287000000b0055384c01797mr3255944edq.62.1703491640106; Mon, 25 Dec 2023 00:07:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703491640; cv=none; d=google.com; s=arc-20160816; b=tRyf7uijy6Y8inuHaFOJSYFx2hTl4W9ZQq/9OYC/drx63juMLhOuo5nZhvPWPM0Gvy CU/I3EPYtULUxTJ1mOnNKsk3kJdkUzufzRlj833mix0GB4H5l9arI7qFCiNWz7gp67Yk s6z9WV8rT8X7QG326MnITdbvzfuxps+LAGc1hKCFhG1V6Fe+gnuN/9WRoe0a6C4mt5gy qfYZvAfGw5CEtKpOZXCHz9iNC7yaXBw8N+KJeDO0R2ma6RCPNT6SvCFwnP2AIxX8Sx9g KqSp/mOd9CGSLAA8MOp+5QeuFGr5VkVOb9kCHWGGadGIbQNk7xowqoETeMZ5FwdHh9fk FSiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=/yEYommBikf7MAh3ERFRd63nlNn/GuyPGg89ypGPars=; fh=iv1MGAx2+K3pJILUpg0RlykEfzkOWQidadOGOPHM2Io=; b=NVzFWIhT1lZK5cqcddYqi0cf85kNvNVLs/zqWzrcO/dnmGDpLQpvHFw0ElIoeawqaA t2NfKrB2LkNB346PyUdPo0KXxu9hZjWa2sagNX+iw5SSZzWx39YuO0sjdo587cyKBp/D dvaKACojJ6PR16zCaoZJCk7eqAZczZAwZVg536hQdBjPKcaoPDChZJQs7FhVLli4Kbhs 1JOzBiMc0qVYLrfsR+odpRhRRVpGWdw0lSWavwtRb2RxKUpqnIOYxpbK4E7xEugdFf7c IB8016Amxq+XoYpAosrTVpzLGXUjYt21Lx5dyFip3us1kqLsXbMAfkxozDMRBHIgA8CS 72TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VSyHvSZM; spf=pass (google.com: domain of linux-kernel+bounces-10945-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-10945-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id m10-20020a056402510a00b0054cd3ad8197si4264495edd.306.2023.12.25.00.07.19 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Dec 2023 00:07:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-10945-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VSyHvSZM; spf=pass (google.com: domain of linux-kernel+bounces-10945-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-10945-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id B65CE1F21E47 for <ouuuleilei@gmail.com>; Mon, 25 Dec 2023 08:07:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E00DC8C03; Mon, 25 Dec 2023 08:06:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VSyHvSZM" X-Original-To: linux-kernel@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8543185A for <linux-kernel@vger.kernel.org>; Mon, 25 Dec 2023 08:06:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1703491607; x=1735027607; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sbhL8XxPds8sXmlf1stkNedv8XeK9UzxN+klgJ58pBg=; b=VSyHvSZMiQO40DjOQ0CpuxYKFfUJxsBhyPfu9dKW3yWub64M0H7GwVMN 5BEFYJg0Sa5De0slNtQhZOgmIwjWlcOYHeQXyQd6EjH/URmIYeRaprqqh Nd6BjwG2DTuRa6Y8/JsnlTTbyjOowVFMZi+/enXMn+7BCe12q/prDtBlF dr5gC4EpsBPRI6/fNJNwpdnHcpvb38s983WQr0MhxutAoRMne11rINoXV pSavOXS/8DRtkgyFTXWtPo74UiKt8HXIKJf1lJGIuwrCKRSHYlDMhTB/j d+FN+tv/X6wuzRWtCNq+Sa4l8llCkWcJ6ZI6/3o2X0dwTknOWRU4To2im g==; X-IronPort-AV: E=McAfee;i="6600,9927,10934"; a="399059645" X-IronPort-AV: E=Sophos;i="6.04,302,1695711600"; d="scan'208";a="399059645" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Dec 2023 00:06:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10934"; a="727474524" X-IronPort-AV: E=Sophos;i="6.04,302,1695711600"; d="scan'208";a="727474524" Received: from flombard-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.50.77]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Dec 2023 00:05:30 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id B7BB1109970; Mon, 25 Dec 2023 11:05:27 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: kirill.shutemov@linux.intel.com Cc: adrian.hunter@intel.com, ashish.kalra@amd.com, bhe@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, elena.reshetova@intel.com, jun.nakajima@intel.com, kai.huang@intel.com, kexec@lists.infradead.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, rafael@kernel.org, rick.p.edgecombe@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, seanjc@google.com, tglx@linutronix.de, thomas.lendacky@amd.com, x86@kernel.org Subject: [PATCHv5.1 14/16] x86/smp: Add smp_ops.stop_this_cpu() callback Date: Mon, 25 Dec 2023 11:05:24 +0300 Message-ID: <20231225080524.4240-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231222235209.32143-15-kirill.shutemov@linux.intel.com> References: <20231222235209.32143-15-kirill.shutemov@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786028361631320746 X-GMAIL-MSGID: 1786240450060849724 |
Series |
None
|
|
Commit Message
Kirill A. Shutemov
Dec. 25, 2023, 8:05 a.m. UTC
If the helper is defined, it is called instead of halt() to stop the CPU
at the end of stop_this_cpu() and on crash CPU shutdown.
ACPI MADT will use it to hand over the CPU to BIOS in order to be able
to wake it up again after kexec.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
v5.1:
- Fix build for !SMP;
---
arch/x86/include/asm/smp.h | 1 +
arch/x86/kernel/process.c | 7 +++++++
arch/x86/kernel/reboot.c | 12 ++++++++----
3 files changed, 16 insertions(+), 4 deletions(-)
Comments
On Mon, 2023-12-25 at 11:05 +0300, Kirill A. Shutemov wrote: > If the helper is defined, it is called instead of halt() to stop the CPU > at the end of stop_this_cpu() and on crash CPU shutdown. > > ACPI MADT will use it to hand over the CPU to BIOS in order to be able > to wake it up again after kexec. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > --- > > v5.1: > - Fix build for !SMP; > > --- > arch/x86/include/asm/smp.h | 1 + > arch/x86/kernel/process.c | 7 +++++++ > arch/x86/kernel/reboot.c | 12 ++++++++---- > 3 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h > index 4fab2ed454f3..390d53fd34f9 100644 > --- a/arch/x86/include/asm/smp.h > +++ b/arch/x86/include/asm/smp.h > @@ -38,6 +38,7 @@ struct smp_ops { > int (*cpu_disable)(void); > void (*cpu_die)(unsigned int cpu); > void (*play_dead)(void); > + void (*stop_this_cpu)(void); > > void (*send_call_func_ipi)(const struct cpumask *mask); > void (*send_call_func_single_ipi)(int cpu); > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > index b6f4e8399fca..ea4c812c7bf3 100644 > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -835,6 +835,13 @@ void __noreturn stop_this_cpu(void *dummy) > */ > cpumask_clear_cpu(cpu, &cpus_stop_mask); > > +#ifdef CONFIG_SMP > + if (smp_ops.stop_this_cpu) { > + smp_ops.stop_this_cpu(); > + unreachable(); > + } > +#endif If I read correctly this will result in stop_this_cpu() having different behaviour for SMP and !SMP build for TDX guest. For example, AFAICT machine_halt() also calls stop_this_cpu() on local cpu after it stops other cpus. So for the local cpu, in SMP build it will calls into BIOS's reset vector but in !SMP it will call native_halt(). > + > for (;;) { > /* > * Use native_halt() so that memory contents don't change > diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c > index 16dde83df49a..738b3e810196 100644 > --- a/arch/x86/kernel/reboot.c > +++ b/arch/x86/kernel/reboot.c > @@ -881,10 +881,14 @@ static int crash_nmi_callback(unsigned int val, struct pt_regs *regs) > cpu_emergency_disable_virtualization(); > > atomic_dec(&waiting_for_crash_ipi); > - /* Assume hlt works */ > - halt(); > - for (;;) > - cpu_relax(); > + > + if (smp_ops.stop_this_cpu) { > + smp_ops.stop_this_cpu(); Could you explain why unreachable() is called in stop_this_cpu() but not here? > + } else { > + halt(); > + for (;;) > + cpu_relax(); > + } Similar to stop_this_cpu(), if you also call unreachable() here, then I think you can remove the 'else' here but directly calls halt() + cpu_relax() loop.
On Mon, Jan 08, 2024 at 03:04:31AM +0000, Huang, Kai wrote: > On Mon, 2023-12-25 at 11:05 +0300, Kirill A. Shutemov wrote: > > If the helper is defined, it is called instead of halt() to stop the CPU > > at the end of stop_this_cpu() and on crash CPU shutdown. > > > > ACPI MADT will use it to hand over the CPU to BIOS in order to be able > > to wake it up again after kexec. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > --- > > > > v5.1: > > - Fix build for !SMP; > > > > --- > > arch/x86/include/asm/smp.h | 1 + > > arch/x86/kernel/process.c | 7 +++++++ > > arch/x86/kernel/reboot.c | 12 ++++++++---- > > 3 files changed, 16 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h > > index 4fab2ed454f3..390d53fd34f9 100644 > > --- a/arch/x86/include/asm/smp.h > > +++ b/arch/x86/include/asm/smp.h > > @@ -38,6 +38,7 @@ struct smp_ops { > > int (*cpu_disable)(void); > > void (*cpu_die)(unsigned int cpu); > > void (*play_dead)(void); > > + void (*stop_this_cpu)(void); > > > > void (*send_call_func_ipi)(const struct cpumask *mask); > > void (*send_call_func_single_ipi)(int cpu); > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index b6f4e8399fca..ea4c812c7bf3 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -835,6 +835,13 @@ void __noreturn stop_this_cpu(void *dummy) > > */ > > cpumask_clear_cpu(cpu, &cpus_stop_mask); > > > > +#ifdef CONFIG_SMP > > + if (smp_ops.stop_this_cpu) { > > + smp_ops.stop_this_cpu(); > > + unreachable(); > > + } > > +#endif > > If I read correctly this will result in stop_this_cpu() having different > behaviour for SMP and !SMP build for TDX guest. For example, AFAICT > machine_halt() also calls stop_this_cpu() on local cpu after it stops other > cpus. So for the local cpu, in SMP build it will calls into BIOS's reset vector > but in !SMP it will call native_halt(). It doesn't make a difference in practice: both halt and giving CPU to BIOS will be unrecoverable operation. Both are equally acceptable for machine_halt(). > > + > > for (;;) { > > /* > > * Use native_halt() so that memory contents don't change > > diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c > > index 16dde83df49a..738b3e810196 100644 > > --- a/arch/x86/kernel/reboot.c > > +++ b/arch/x86/kernel/reboot.c > > @@ -881,10 +881,14 @@ static int crash_nmi_callback(unsigned int val, struct pt_regs *regs) > > cpu_emergency_disable_virtualization(); > > > > atomic_dec(&waiting_for_crash_ipi); > > - /* Assume hlt works */ > > - halt(); > > - for (;;) > > - cpu_relax(); > > + > > + if (smp_ops.stop_this_cpu) { > > + smp_ops.stop_this_cpu(); > > Could you explain why unreachable() is called in stop_this_cpu() but not here? Compiler complained previously on stop_this_cpu() when it had halt() in 'else' case because the function is declared as __noreturn. I left unreachable() after reworking it without 'else' to document the behaviour. > > + } else { > > + halt(); > > + for (;;) > > + cpu_relax(); > > + } > > Similar to stop_this_cpu(), if you also call unreachable() here, then I think > you can remove the 'else' here but directly calls halt() + cpu_relax() loop. It doesn't make much difference to me. But okay, I will rework it the same way in the next version.
> > > @@ -835,6 +835,13 @@ void __noreturn stop_this_cpu(void *dummy) > > > */ > > > cpumask_clear_cpu(cpu, &cpus_stop_mask); > > > > > > +#ifdef CONFIG_SMP > > > + if (smp_ops.stop_this_cpu) { > > > + smp_ops.stop_this_cpu(); > > > + unreachable(); > > > + } > > > +#endif > > > > If I read correctly this will result in stop_this_cpu() having different > > behaviour for SMP and !SMP build for TDX guest. For example, AFAICT > > machine_halt() also calls stop_this_cpu() on local cpu after it stops other > > cpus. So for the local cpu, in SMP build it will calls into BIOS's reset vector > > but in !SMP it will call native_halt(). > > It doesn't make a difference in practice: both halt and giving CPU to > BIOS will be unrecoverable operation. Both are equally acceptable for > machine_halt(). > OK fair enough. :-)
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 4fab2ed454f3..390d53fd34f9 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -38,6 +38,7 @@ struct smp_ops { int (*cpu_disable)(void); void (*cpu_die)(unsigned int cpu); void (*play_dead)(void); + void (*stop_this_cpu)(void); void (*send_call_func_ipi)(const struct cpumask *mask); void (*send_call_func_single_ipi)(int cpu); diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index b6f4e8399fca..ea4c812c7bf3 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -835,6 +835,13 @@ void __noreturn stop_this_cpu(void *dummy) */ cpumask_clear_cpu(cpu, &cpus_stop_mask); +#ifdef CONFIG_SMP + if (smp_ops.stop_this_cpu) { + smp_ops.stop_this_cpu(); + unreachable(); + } +#endif + for (;;) { /* * Use native_halt() so that memory contents don't change diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index 16dde83df49a..738b3e810196 100644 --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@ -881,10 +881,14 @@ static int crash_nmi_callback(unsigned int val, struct pt_regs *regs) cpu_emergency_disable_virtualization(); atomic_dec(&waiting_for_crash_ipi); - /* Assume hlt works */ - halt(); - for (;;) - cpu_relax(); + + if (smp_ops.stop_this_cpu) { + smp_ops.stop_this_cpu(); + } else { + halt(); + for (;;) + cpu_relax(); + } return NMI_HANDLED; }