mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Michal Pecio <michal.pecio@gmail.com>,
	Eric DeVolder <eric.devolder@oracle.com>
Subject: Re: [PATCH] x86/acpi/boot: Correct acpi_is_processor_usable() check again
Date: Thu, 13 Nov 2025 08:30:27 -0600	[thread overview]
Message-ID: <e89951cf-3a1a-4ce5-92d0-2ba63e2fd94b@amd.com> (raw)
In-Reply-To: <20251113142713.GBaRXqweHEuZw1bjD1@fat_crate.local>

On 11/13/25 8:27 AM, Borislav Petkov wrote:
> Seems to work here, I will run it on a couple more machines and even if it is
> stable material, I'd let it go through a full cycle merge window so that it
> sees more testing.
> 
> Thx.
> 
> ---
> From: Yazen Ghannam <yazen.ghannam@amd.com>
> Date: Tue, 11 Nov 2025 14:53:57 +0000
> 
> ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is
> used in conjunction with the "Enabled" MADT LAPIC flag to determine if
> a CPU can be enabled/hotplugged by the OS after boot.
> 
> Before the new bit was defined, the "Enabled" bit was explicitly
> described like this (ACPI v6.0 wording provided):
> 
>    "If zero, this processor is unusable, and the operating system
>    support will not attempt to use it"
> 
> This means that CPU hotplug (based on MADT) is not possible. Many BIOS
> implementations follow this guidance. They may include LAPIC entries in
> MADT for unavailable CPUs, but since these entries are marked with
> "Enabled=0" it is expected that the OS will completely ignore these
> entries.
> 
> However, QEMU will do the same (include entries with "Enabled=0") for
> the purpose of allowing CPU hotplug within the guest.
> 
> Comment from QEMU function pc_madt_cpu_entry():
> 
>    /* ACPI spec says that LAPIC entry for non present
>     * CPU may be omitted from MADT or it must be marked
>     * as disabled. However omitting non present CPU from
>     * MADT breaks hotplug on linux. So possible CPUs
>     * should be put in MADT but kept disabled.
>     */
> 
> Recent Linux topology changes broke the QEMU use case. A following fix
> for the QEMU use case broke bare metal topology enumeration.
> 
> Rework the Linux MADT LAPIC flags check to allow the QEMU use case only
> for guests and to maintain the ACPI spec behavior for bare metal.
> 
> Remove an unnecessary check added to fix a bare metal case introduced by
> the QEMU "fix".
> 
>    [ bp: Change logic as Michal suggested. ]
> 
> Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() check")
> Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a present package")
> Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com
> Reported-by: Michal Pecio <michal.pecio@gmail.com>
> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> Tested-by: Michal Pecio <michal.pecio@gmail.com>
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/20251111145357.4031846-1-yazen.ghannam@amd.com
> ---
>   arch/x86/kernel/acpi/boot.c    | 12 ++++++++----
>   arch/x86/kernel/cpu/topology.c | 15 ---------------
>   2 files changed, 8 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 9fa321a95eb3..d6138b2b633a 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -35,6 +35,7 @@
>   #include <asm/smp.h>
>   #include <asm/i8259.h>
>   #include <asm/setup.h>
> +#include <asm/hypervisor.h>
>   
>   #include "sleep.h" /* To include x86_acpi_suspend_lowlevel */
>   static int __initdata acpi_force = 0;
> @@ -164,11 +165,14 @@ static bool __init acpi_is_processor_usable(u32 lapic_flags)
>   	if (lapic_flags & ACPI_MADT_ENABLED)
>   		return true;
>   
> -	if (!acpi_support_online_capable ||
> -	    (lapic_flags & ACPI_MADT_ONLINE_CAPABLE))
> -		return true;
> +	if (acpi_support_online_capable)
> +		return lapic_flags & ACPI_MADT_ONLINE_CAPABLE;
>   
> -	return false;
> +	/*
> +	 * QEMU expects legacy "Enabled=0" LAPIC entries to be counted as usable
> +	 * in order to support CPU hotplug in guests.
> +	 */

I think it would be good to amend this comment to indicate that the 
behavior of the "enabled bit" changed and that QEMU follows the newer 
behavior but advertises the older version.

> +	return !hypervisor_is_type(X86_HYPER_NATIVE);
>   }
>   
>   static int __init
> diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
> index 6073a16628f9..425404e7b7b4 100644
> --- a/arch/x86/kernel/cpu/topology.c
> +++ b/arch/x86/kernel/cpu/topology.c
> @@ -27,7 +27,6 @@
>   #include <xen/xen.h>
>   
>   #include <asm/apic.h>
> -#include <asm/hypervisor.h>
>   #include <asm/io_apic.h>
>   #include <asm/mpspec.h>
>   #include <asm/msr.h>
> @@ -240,20 +239,6 @@ static __init void topo_register_apic(u32 apic_id, u32 acpi_id, bool present)
>   		cpuid_to_apicid[cpu] = apic_id;
>   		topo_set_cpuids(cpu, apic_id, acpi_id);
>   	} else {
> -		u32 pkgid = topo_apicid(apic_id, TOPO_PKG_DOMAIN);
> -
> -		/*
> -		 * Check for present APICs in the same package when running
> -		 * on bare metal. Allow the bogosity in a guest.
> -		 */
> -		if (hypervisor_is_type(X86_HYPER_NATIVE) &&
> -		    topo_unit_count(pkgid, TOPO_PKG_DOMAIN, phys_cpu_present_map)) {
> -			pr_info_once("Ignoring hot-pluggable APIC ID %x in present package.\n",
> -				     apic_id);
> -			topo_info.nr_rejected_cpus++;
> -			return;
> -		}
> -
>   		topo_info.nr_disabled_cpus++;
>   	}
>   


  reply	other threads:[~2025-11-13 14:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 14:53 Yazen Ghannam
2025-11-12 13:56 ` Borislav Petkov
2025-11-12 16:35   ` Mario Limonciello
2025-11-12 17:21     ` Borislav Petkov
2025-11-13 14:27       ` Borislav Petkov
2025-11-13 14:30         ` Mario Limonciello [this message]
2025-11-13 14:34           ` Borislav Petkov
2025-11-13 14:55             ` Mario Limonciello
2025-11-12 18:05 ` Michal Pecio
2025-11-12 19:17   ` Borislav Petkov
2025-11-14 16:23 ` Ricardo Neri
2025-11-14 16:53   ` Borislav Petkov

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=e89951cf-3a1a-4ce5-92d0-2ba63e2fd94b@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=bp@alien8.de \
    --cc=eric.devolder@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.pecio@gmail.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®