Message ID | 20231020151242.1814-12-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2010:b0:403:3b70:6f57 with SMTP id fe16csp1125762vqb; Fri, 20 Oct 2023 08:13:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEaNJZjJ/zp/R7ZQWHKFxTPo+O0D8FdX33PT7xjxUmvU/PQl2wz0q7Z0L866esRZ+qwdIty X-Received: by 2002:a17:902:d484:b0:1c9:cf1e:f907 with SMTP id c4-20020a170902d48400b001c9cf1ef907mr2840697plg.57.1697814832366; Fri, 20 Oct 2023 08:13:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697814832; cv=none; d=google.com; s=arc-20160816; b=hyd6cRJnsjg+ZyOdrzYQGZ9DnT/4yyJ4cS9mkgJJlNVrSDaLCYJ4xtc//BNxpHIKpv SGW6cc6aLBy19i9aD/bTBYjM+Py537hQD3wLiTBD77XZ4QT+m7lQhlLNzXUApLuonV5B 4GubJuOdt2XKutNFFtQ2XnumZU4bE5rwP6ZAANSr9zmMw4Zaw9pLZu5Fag1sLwCzKITR 8qlIAt9v1u4jza0vqI9BsqQXBaen8ZkYl25cDOnj0vkUVTJLVwYSj1KHBVttgdcSceML 74u3u4yEz5W+oB5ZJVlKVmM0a9oGP4TpqKxFn6Eb5lkH3igYVfdGcCuVC83v0nZv4fAK GaJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=OILuZGF/OVKHh5gzWzvZCXJOvDRazlSL9Eaqt+ps2Hg=; fh=OvJRnOqsMTm9XoNmEwebcqh9Ud7yh1CTeKAP84ols98=; b=gAiDomcCEcnmYcCIGyZDNLbu48yTMf+HmeiWbGTHGbPBrpksMk/rqik1oW/tMloCyT B2vTZq8jQluoplrUzq0E+TqsumBNIluWA/ysm3QFCJuKQwQ6CeAXlNWTrhbhDWh62VOv HmChY4KL183GThDq78xNpXlVMVEaCJgMDJg84CW/dwoyCqirh4pZHLA9AO1Scj1Fqiqu 206r7+G8cfimsR0muXToTtN0iHUzDFW0Okh0VyLpoM2rLCyxcARAJiKpCkOVmuR4HIy/ 4StXYmSutbZGBL4Nv554gaVHWEAl0vCXxyWJCQOd+5iEknUa0LsJ4QiTsORDUMZwtk8a UIhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eBfDKdI8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id c7-20020a170902b68700b001c737001bb3si1854011pls.345.2023.10.20.08.13.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 08:13:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eBfDKdI8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 810E3803D816; Fri, 20 Oct 2023 08:13:49 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377644AbjJTPNT (ORCPT <rfc822;a1648639935@gmail.com> + 26 others); Fri, 20 Oct 2023 11:13:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377650AbjJTPNM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Oct 2023 11:13:12 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8D31D7B for <linux-kernel@vger.kernel.org>; Fri, 20 Oct 2023 08:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697814784; x=1729350784; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=OLVOdxFnd1PuTcNaoWBVdKJvyZnZKOsxD6fGknmiUv0=; b=eBfDKdI84lEnBrHqq91rR3djTOLizxToQglynzeV9IX/wor4SOLT8lea HhXNSf2MLox4td8IY6Gl8BnEuG3rIUKWCEnISKXU8QwQmy65WAs64LDxP xv82WTHctLP+0q8t3mYcugM5EyLFCG3mrmiDz1L7tUXjfXuvFJPDQT4mC DCoIpQDoq/VJJfPu4U6yKvUXzwNP+cf0bWQlcvMjJkW7kEYOqXFxu9cuo cTK8PcR8dQgX+Hiho1QJVBaz9LpMChiOyArUb/RLCmqrBol/etMiWOI4f smRdvM5bsKc4pVu0qbqQe+nVx9hwLiV9fYUzDn50XKi1361k01O6Qqts6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10869"; a="376893672" X-IronPort-AV: E=Sophos;i="6.03,239,1694761200"; d="scan'208";a="376893672" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2023 08:13:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10869"; a="761080288" X-IronPort-AV: E=Sophos;i="6.03,239,1694761200"; d="scan'208";a="761080288" Received: from dgutows1-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.249.39.237]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2023 08:12:56 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 5C61110A29D; Fri, 20 Oct 2023 18:12:45 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Adrian Hunter <adrian.hunter@intel.com>, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Elena Reshetova <elena.reshetova@intel.com>, Jun Nakajima <jun.nakajima@intel.com>, Rick Edgecombe <rick.p.edgecombe@intel.com>, Tom Lendacky <thomas.lendacky@amd.com>, "Kalra, Ashish" <ashish.kalra@amd.com>, Sean Christopherson <seanjc@google.com>, "Huang, Kai" <kai.huang@intel.com>, Baoquan He <bhe@redhat.com>, kexec@lists.infradead.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCHv2 11/13] x86/acpi: Do not attempt to bring up secondary CPUs in kexec case Date: Fri, 20 Oct 2023 18:12:40 +0300 Message-ID: <20231020151242.1814-12-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231020151242.1814-1-kirill.shutemov@linux.intel.com> References: <20231020151242.1814-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Fri, 20 Oct 2023 08:13:49 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780287885932074934 X-GMAIL-MSGID: 1780287885932074934 |
Series |
x86/tdx: Add kexec support
|
|
Commit Message
Kirill A. Shutemov
Oct. 20, 2023, 3:12 p.m. UTC
ACPI MADT doesn't allow to offline CPU after it got woke up. It limits
kexec: the second kernel won't be able to use more than one CPU.
Now acpi_mp_wake_mailbox_paddr already has the mailbox address.
The acpi_wakeup_cpu() will use it to bring up secondary cpus.
Zero out mailbox address in the ACPI MADT wakeup structure to indicate
that the mailbox is not usable. This prevents the kexec()-ed kernel
from reading a vaild mailbox, which in turn makes the kexec()-ed kernel
only be able to use the boot CPU.
This is Linux-specific protocol and not reflected in ACPI spec.
Booting the second kernel with signle CPU is enough to cover the most
common case for kexec -- kdump.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
arch/x86/kernel/acpi/madt_wakeup.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
Comments
On Fri, 2023-10-20 at 18:12 +0300, Kirill A. Shutemov wrote: > ACPI MADT doesn't allow to offline CPU after it got woke up. It limits > kexec: the second kernel won't be able to use more than one CPU. > > Now acpi_mp_wake_mailbox_paddr already has the mailbox address. > The acpi_wakeup_cpu() will use it to bring up secondary cpus. > > Zero out mailbox address in the ACPI MADT wakeup structure to indicate > that the mailbox is not usable. This prevents the kexec()-ed kernel > from reading a vaild mailbox, which in turn makes the kexec()-ed kernel > only be able to use the boot CPU. > > This is Linux-specific protocol and not reflected in ACPI spec. > > Booting the second kernel with signle CPU is enough to cover the most > common case for kexec -- kdump. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Kai Huang <kai.huang@intel.com>
On 10/20/2023 8:12 AM, Kirill A. Shutemov wrote: > ACPI MADT doesn't allow to offline CPU after it got woke up. It limits > kexec: the second kernel won't be able to use more than one CPU. > > Now acpi_mp_wake_mailbox_paddr already has the mailbox address. > The acpi_wakeup_cpu() will use it to bring up secondary cpus. > > Zero out mailbox address in the ACPI MADT wakeup structure to indicate > that the mailbox is not usable. This prevents the kexec()-ed kernel > from reading a vaild mailbox, which in turn makes the kexec()-ed kernel > only be able to use the boot CPU. > > This is Linux-specific protocol and not reflected in ACPI spec. > > Booting the second kernel with signle CPU is enough to cover the most > common case for kexec -- kdump. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > --- > arch/x86/kernel/acpi/madt_wakeup.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/arch/x86/kernel/acpi/madt_wakeup.c b/arch/x86/kernel/acpi/madt_wakeup.c > index 4bc1d5106afd..9bbe829737e7 100644 > --- a/arch/x86/kernel/acpi/madt_wakeup.c > +++ b/arch/x86/kernel/acpi/madt_wakeup.c > @@ -13,6 +13,11 @@ static struct acpi_madt_multiproc_wakeup_mailbox *acpi_mp_wake_mailbox; > > static int acpi_wakeup_cpu(int apicid, unsigned long start_ip) > { > + if (!acpi_mp_wake_mailbox_paddr) { > + pr_warn_once("No MADT mailbox: cannot bringup secondary CPUs. Booting with kexec?\n"); > + return -EOPNOTSUPP; > + } > + > /* > * Remap mailbox memory only for the first call to acpi_wakeup_cpu(). > * > @@ -78,6 +83,23 @@ int __init acpi_parse_mp_wake(union acpi_subtable_headers *header, > > cpu_hotplug_disable_offlining(); > > + /* > + * ACPI MADT doesn't allow to offline CPU after it got woke up. > + * It limits kexec: the second kernel won't be able to use more than > + * one CPU. > + * > + * Now acpi_mp_wake_mailbox_paddr already has the mailbox address. > + * The acpi_wakeup_cpu() will use it to bring up secondary cpus. > + * > + * Zero out mailbox address in the ACPI MADT wakeup structure to > + * indicate that the mailbox is not usable. This prevents the > + * kexec()-ed kernel from reading a vaild mailbox, which in turn > + * makes the kexec()-ed kernel only be able to use the boot CPU. > + * > + * This is Linux-specific protocol and not reflected in ACPI spec. > + */ > + mp_wake->base_address = 0; Is there any way to skip secondary CPU bring-up for kexec case instead of returning error in ->wakeup_secondary_cpu_64()? > + > apic_update_callback(wakeup_secondary_cpu_64, acpi_wakeup_cpu); > > return 0;
On Tue, Oct 24, 2023 at 06:59:58AM -0700, Kuppuswamy Sathyanarayanan wrote: > > > On 10/20/2023 8:12 AM, Kirill A. Shutemov wrote: > > ACPI MADT doesn't allow to offline CPU after it got woke up. It limits > > kexec: the second kernel won't be able to use more than one CPU. > > > > Now acpi_mp_wake_mailbox_paddr already has the mailbox address. > > The acpi_wakeup_cpu() will use it to bring up secondary cpus. > > > > Zero out mailbox address in the ACPI MADT wakeup structure to indicate > > that the mailbox is not usable. This prevents the kexec()-ed kernel > > from reading a vaild mailbox, which in turn makes the kexec()-ed kernel > > only be able to use the boot CPU. > > > > This is Linux-specific protocol and not reflected in ACPI spec. > > > > Booting the second kernel with signle CPU is enough to cover the most > > common case for kexec -- kdump. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > --- > > arch/x86/kernel/acpi/madt_wakeup.c | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/arch/x86/kernel/acpi/madt_wakeup.c b/arch/x86/kernel/acpi/madt_wakeup.c > > index 4bc1d5106afd..9bbe829737e7 100644 > > --- a/arch/x86/kernel/acpi/madt_wakeup.c > > +++ b/arch/x86/kernel/acpi/madt_wakeup.c > > @@ -13,6 +13,11 @@ static struct acpi_madt_multiproc_wakeup_mailbox *acpi_mp_wake_mailbox; > > > > static int acpi_wakeup_cpu(int apicid, unsigned long start_ip) > > { > > + if (!acpi_mp_wake_mailbox_paddr) { > > + pr_warn_once("No MADT mailbox: cannot bringup secondary CPUs. Booting with kexec?\n"); > > + return -EOPNOTSUPP; > > + } > > + > > /* > > * Remap mailbox memory only for the first call to acpi_wakeup_cpu(). > > * > > @@ -78,6 +83,23 @@ int __init acpi_parse_mp_wake(union acpi_subtable_headers *header, > > > > cpu_hotplug_disable_offlining(); > > > > + /* > > + * ACPI MADT doesn't allow to offline CPU after it got woke up. > > + * It limits kexec: the second kernel won't be able to use more than > > + * one CPU. > > + * > > + * Now acpi_mp_wake_mailbox_paddr already has the mailbox address. > > + * The acpi_wakeup_cpu() will use it to bring up secondary cpus. > > + * > > + * Zero out mailbox address in the ACPI MADT wakeup structure to > > + * indicate that the mailbox is not usable. This prevents the > > + * kexec()-ed kernel from reading a vaild mailbox, which in turn > > + * makes the kexec()-ed kernel only be able to use the boot CPU. > > + * > > + * This is Linux-specific protocol and not reflected in ACPI spec. > > + */ > > + mp_wake->base_address = 0; > > Is there any way to skip secondary CPU bring-up for kexec case instead of > returning error in ->wakeup_secondary_cpu_64()? I have not found a cleaner way. Do you have ideas?
diff --git a/arch/x86/kernel/acpi/madt_wakeup.c b/arch/x86/kernel/acpi/madt_wakeup.c index 4bc1d5106afd..9bbe829737e7 100644 --- a/arch/x86/kernel/acpi/madt_wakeup.c +++ b/arch/x86/kernel/acpi/madt_wakeup.c @@ -13,6 +13,11 @@ static struct acpi_madt_multiproc_wakeup_mailbox *acpi_mp_wake_mailbox; static int acpi_wakeup_cpu(int apicid, unsigned long start_ip) { + if (!acpi_mp_wake_mailbox_paddr) { + pr_warn_once("No MADT mailbox: cannot bringup secondary CPUs. Booting with kexec?\n"); + return -EOPNOTSUPP; + } + /* * Remap mailbox memory only for the first call to acpi_wakeup_cpu(). * @@ -78,6 +83,23 @@ int __init acpi_parse_mp_wake(union acpi_subtable_headers *header, cpu_hotplug_disable_offlining(); + /* + * ACPI MADT doesn't allow to offline CPU after it got woke up. + * It limits kexec: the second kernel won't be able to use more than + * one CPU. + * + * Now acpi_mp_wake_mailbox_paddr already has the mailbox address. + * The acpi_wakeup_cpu() will use it to bring up secondary cpus. + * + * Zero out mailbox address in the ACPI MADT wakeup structure to + * indicate that the mailbox is not usable. This prevents the + * kexec()-ed kernel from reading a vaild mailbox, which in turn + * makes the kexec()-ed kernel only be able to use the boot CPU. + * + * This is Linux-specific protocol and not reflected in ACPI spec. + */ + mp_wake->base_address = 0; + apic_update_callback(wakeup_secondary_cpu_64, acpi_wakeup_cpu); return 0;