LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexander Deucher <Alexander.Deucher@amd.com>,
	Ray Huang <Ray.Huang@amd.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Robert Moore <robert.moore@intel.com>,
	Erik Kaneda <erik.kaneda@intel.com>,
	"open list:SUSPEND TO RAM" <linux-pm@vger.kernel.org>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>,
	"open list:ACPI" <linux-acpi@vger.kernel.org>,
	"open list:ACPI COMPONENT ARCHITECTURE (ACPICA)"
	<devel@acpica.org>
Subject: Re: [PATCH v2] x86/acpi: Don't add CPUs that are not online capable
Date: Mon, 16 Aug 2021 16:04:57 +0200	[thread overview]
Message-ID: <CAJZ5v0jynpMMnMBQuyJPYfSG-6JSe5=a6wW0UtUnpGuh68CqkA@mail.gmail.com> (raw)
In-Reply-To: <20210813161842.222414-1-mario.limonciello@amd.com>

On Fri, Aug 13, 2021 at 6:19 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> A number of systems are showing "hotplug capable" CPUs when they
> are not really hotpluggable.  This is because the MADT has extra
> CPU entries to support different CPUs that may be inserted into
> the socket with different numbers of cores.
>
> Starting with ACPI 6.3 the spec has an Online Capable bit in the
> MADT used to determine whether or not a CPU is hotplug capable
> when the enabled bit is not set.
>
> Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html?#local-apic-flags
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
>  arch/x86/kernel/acpi/boot.c | 10 ++++++++++
>  include/acpi/actbl2.h       |  1 +
>  2 files changed, 11 insertions(+)
>
> Changes from v1->v2:
>  * Check the revision field in MADT to determine if it matches the
>    bump from ACPI 6.3 as suggested by Hanjun Guo
>  * Update description
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index e55e0c1fad8c..bfa69a5c9c0b 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -53,6 +53,8 @@ int acpi_ioapic;
>  int acpi_strict;
>  int acpi_disable_cmcff;
>
> +bool acpi_support_online_capable;

Missing static?

> +
>  /* ACPI SCI override configuration */
>  u8 acpi_sci_flags __initdata;
>  u32 acpi_sci_override_gsi __initdata = INVALID_ACPI_IRQ;
> @@ -138,6 +140,8 @@ static int __init acpi_parse_madt(struct acpi_table_header *table)
>
>                 pr_debug("Local APIC address 0x%08x\n", madt->address);
>         }
> +       if (madt->header.revision >= 5)
> +               acpi_support_online_capable = true;
>
>         default_acpi_madt_oem_check(madt->header.oem_id,
>                                     madt->header.oem_table_id);
> @@ -239,6 +243,12 @@ acpi_parse_lapic(union acpi_subtable_headers * header, const unsigned long end)
>         if (processor->id == 0xff)
>                 return 0;
>
> +       /* don't register processors that can not be onlined */
> +       if (acpi_support_online_capable &&
> +           !(processor->lapic_flags & ACPI_MADT_ENABLED) &&
> +           !(processor->lapic_flags & ACPI_MADT_ONLINE_CAPABLE))
> +               return 0;
> +
>         /*
>          * We need to register disabled CPU as well to permit
>          * counting disabled CPUs. This allows us to size
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index 2069ac38a4e2..fae45e383987 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h

The one below is an ACPICA change and I'd prefer it to be integrated
via the upstream ACPICA.

Could you prepare an ACPICA pull request for just the bit below and
send it via GitHub?

> @@ -808,6 +808,7 @@ struct acpi_madt_multiproc_wakeup_mailbox {
>  /* MADT Local APIC flags */
>
>  #define ACPI_MADT_ENABLED           (1)        /* 00: Processor is usable if set */
> +#define ACPI_MADT_ONLINE_CAPABLE    (2)        /* 01: System HW supports enabling processor at runtime */
>
>  /* MADT MPS INTI flags (inti_flags) */
>
> --

  reply	other threads:[~2021-08-16 14:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 16:18 Mario Limonciello
2021-08-16 14:04 ` Rafael J. Wysocki [this message]
2021-08-17 18:41   ` Limonciello, Mario
2021-08-31 18:51     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJZ5v0jynpMMnMBQuyJPYfSG-6JSe5=a6wW0UtUnpGuh68CqkA@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=Alexander.Deucher@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=bp@alien8.de \
    --cc=devel@acpica.org \
    --cc=erik.kaneda@intel.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH v2] x86/acpi: Don'\''t add CPUs that are not online capable' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).