From: Eric DeVolder <eric.devolder@oracle.com>
To: rafael@kernel.org, lenb@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, mario.limonciello@amd.com,
kvijayab@amd.com
Cc: miguel.luis@oracle.com, boris.ostrovsky@oracle.com,
eric.devolder@oracle.com
Subject: [PATCH 0/1] x86/acpi: acpi_is_processor_usable() dropping possible cpus
Date: Mon, 27 Mar 2023 15:10:25 -0400 [thread overview]
Message-ID: <20230327191026.3454-1-eric.devolder@oracle.com> (raw)
I've been working on a patch series for cpu hotplug and kdump and
noticed recently that utilizing a QEMU guest to test cpu hotplug was
causing the following error messages:
APIC: NR_CPUS/possible_cpus limit of 30 reached. Processor 30/0x.
ACPI: Unable to map lapic to logical cpu number
acpi LNXCPU:1e: Enumeration failure
where prior cpu hotplug would typically result in messages similar to:
CPU30 has been hot-added
smpboot: Booting Node 0 Processor 30 APIC 0x1e
Will online and init hotplugged CPU: 30
The QEMU guest incantation was:
qemu-system-x86_64 -smp 30,maxcpus=32 ...
A simple guest with 30 cpus and possiblly up to 32, meaning two hot
pluggable.
An investigation lead to finding the following relevant changes:
commit aa06e20f1be6 ("x86/acpi: Don't add CPUs that are not online capable")
commit e2869bd7af60 ("x86/acpi/boot: Do not register processors that cannot be onlined for x2APIC")
The first patch codes the fact that ACPI 6.3 now features an Online
Capable bit in MADT.revision >= 5. This Online Capable bit explicitly
indicates that the cpu can be hotplugged.
The second patch refactors the first a bit in order to apply the same
logic for both lapic and x2apic. However, there is a subtle change in
the logic to this patch that breaks for MADT.revision prior to 5.
As it turns out, QEMU reports revision 1 in the MADT table for x86.
(Technically QEMU is at revision 4, and I'll be addressing that with
the QEMU folks soon.)
In looking at these patches and understanding the logic, I can sum it
up by stating that prior to MADT revision 5, the presence of a
lapic/x2apic structure _implicitly_ was used to determine that a cpu
might be hotpluggable, and it would count towards possible cpus. With
MADT.revision >= 5, that implicit assumption is now replaced with an
explicit indication.
The manner in which the latest patch is coded, it essentially requires
the Online Capable bit introduced at MADT.revision >= 5 be set for
present-but-offline cpus, else it excludes the cpu from the possible
cpus. Thus for MADT.revision < 5, possible cpus are being dropped.
This patch aims to restore the behavior for MADT.revision prior to 5
which facilitates again cpu hotplug for QEMU guests.
Regards,
eric
---
Eric DeVolder (1):
x86/acpi: acpi_is_processor_usable() dropping possible cpus
arch/x86/kernel/acpi/boot.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--
2.31.1
next reply other threads:[~2023-03-27 19:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 19:10 Eric DeVolder [this message]
2023-03-27 19:10 ` [PATCH 1/1] x86/acpi: acpi_is_processor_usable() dropping possible cpus Eric DeVolder
2023-03-27 19:57 ` Borislav Petkov
2023-03-27 20:07 ` Eric DeVolder
2023-03-27 20:25 ` Borislav Petkov
2023-03-29 19:34 ` Limonciello, Mario
2023-03-29 19:35 ` Limonciello, Mario
2023-03-30 9:33 ` [tip: x86/urgent] x86/acpi/boot: Correct acpi_is_processor_usable() check tip-bot2 for Eric DeVolder
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=20230327191026.3454-1-eric.devolder@oracle.com \
--to=eric.devolder@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvijayab@amd.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=miguel.luis@oracle.com \
--cc=mingo@redhat.com \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.