From: Thomas Gleixner <tglx@linutronix.de>
To: Lyude Paul <lyude@redhat.com>,
"Linux regression tracking (Thorsten Leemhuis)"
<regressions@leemhuis.info>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Mario Limonciello <mario.limonciello@amd.com>,
Borislav Petkov <bp@alien8.de>,
Linux kernel regressions list <regressions@lists.linux.dev>
Subject: Re: Early boot regression from f0551af0213 ("x86/topology: Ignore non-present APIC IDs in a present package")
Date: Thu, 23 May 2024 00:12:47 +0200 [thread overview]
Message-ID: <874japh4ww.ffs@tglx> (raw)
In-Reply-To: <d4496b4ed8a8a7bb34cf12e4cce65a6ad6705bc0.camel@redhat.com>
Lyude!
On Wed, May 22 2024 at 15:35, Lyude Paul wrote:
Thank for testing!
> Awesome! This patch does seem to make the system boot, thank you for
> your help
The only thing what's awesome here is that it confirms my analysis of
the underlying problem. I offered Borislav a bet on that, but he
politely declined :(
The not so awesome part is the question what to do with that insight.
The first issue is that we don't know whether that's only a problem on
your particular system or if there is an underlying systematic problem
on that particular CPU variant (model/stepping).
Unless the AMD folks can give an authoritative answer we have three options:
1) Targeted via quirk
As you are so far the only one complaining about this, it might be
sufficient to enforce the physical flat mode for your particular
machine via a DMI quirk or on the actual CPU model/stepping.
2) Tie it to interrupt remapping
That's the patch I provided you for testing
3) Remove the default logical destination mode on 64bit completely
My favourite
#1 is stupid IMO because it's likely that other systems are affected by
this nonsense and I don't want to end up adding quirks over and over
#2 is silly because it effectively enforces physical destination mode on
any system which has interrupt remapping available in hardware.
That's pretty much everything halfways modern.
#3 makes a lot of sense because:
- it reduces the amount of code
Given the trend of the last decade this actually removes code which
will be used less frequently as the number of logical CPUs keeps
increasing.
- the only benefit of logical destination mode over physical
destination mode is the ability to send IPIs to multiple CPUs in
one operation.
The question is whether this still matters.
IMO it does not matter because anything which is IPI sensitive is
running on machines which have more than 8 CPUs today. The time
where 8 CPU (threads) workstations and servers were state of the
art are long gone.
- physical destination mode is guaranteed to work because it's the
only way to get a CPU up and running via the INIT/INIT/STARTUP
sequence, while obvioulsy logical destination mode has its issues
not only on the system at hand (see physflat_acpi_madt_oem_check()).
Patch for this below.
Thanks,
tglx
---
arch/x86/kernel/apic/apic_flat_64.c | 116 ------------------------------------
1 file changed, 3 insertions(+), 113 deletions(-)
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -18,126 +18,19 @@
#include "local.h"
static struct apic apic_physflat;
-static struct apic apic_flat;
-struct apic *apic __ro_after_init = &apic_flat;
+struct apic *apic __ro_after_init = &apic_phys_flat;
EXPORT_SYMBOL_GPL(apic);
-static int flat_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
-{
- return 1;
-}
-
-static void _flat_send_IPI_mask(unsigned long mask, int vector)
-{
- unsigned long flags;
-
- local_irq_save(flags);
- __default_send_IPI_dest_field(mask, vector, APIC_DEST_LOGICAL);
- local_irq_restore(flags);
-}
-
-static void flat_send_IPI_mask(const struct cpumask *cpumask, int vector)
-{
- unsigned long mask = cpumask_bits(cpumask)[0];
-
- _flat_send_IPI_mask(mask, vector);
-}
-
-static void
-flat_send_IPI_mask_allbutself(const struct cpumask *cpumask, int vector)
-{
- unsigned long mask = cpumask_bits(cpumask)[0];
- int cpu = smp_processor_id();
-
- if (cpu < BITS_PER_LONG)
- __clear_bit(cpu, &mask);
-
- _flat_send_IPI_mask(mask, vector);
-}
-
-static u32 flat_get_apic_id(u32 x)
-{
- return (x >> 24) & 0xFF;
-}
-
-static int flat_probe(void)
-{
- return 1;
-}
-
-static struct apic apic_flat __ro_after_init = {
- .name = "flat",
- .probe = flat_probe,
- .acpi_madt_oem_check = flat_acpi_madt_oem_check,
-
- .dest_mode_logical = true,
-
- .disable_esr = 0,
-
- .init_apic_ldr = default_init_apic_ldr,
- .cpu_present_to_apicid = default_cpu_present_to_apicid,
-
- .max_apic_id = 0xFE,
- .get_apic_id = flat_get_apic_id,
-
- .calc_dest_apicid = apic_flat_calc_apicid,
-
- .send_IPI = default_send_IPI_single,
- .send_IPI_mask = flat_send_IPI_mask,
- .send_IPI_mask_allbutself = flat_send_IPI_mask_allbutself,
- .send_IPI_allbutself = default_send_IPI_allbutself,
- .send_IPI_all = default_send_IPI_all,
- .send_IPI_self = default_send_IPI_self,
- .nmi_to_offline_cpu = true,
-
- .read = native_apic_mem_read,
- .write = native_apic_mem_write,
- .eoi = native_apic_mem_eoi,
- .icr_read = native_apic_icr_read,
- .icr_write = native_apic_icr_write,
- .wait_icr_idle = apic_mem_wait_icr_idle,
- .safe_wait_icr_idle = apic_mem_wait_icr_idle_timeout,
-};
-
-/*
- * Physflat mode is used when there are more than 8 CPUs on a system.
- * We cannot use logical delivery in this case because the mask
- * overflows, so use physical mode.
- */
-static int physflat_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
-{
-#ifdef CONFIG_ACPI
- /*
- * Quirk: some x86_64 machines can only use physical APIC mode
- * regardless of how many processors are present (x86_64 ES7000
- * is an example).
- */
- if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
- (acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL)) {
- printk(KERN_DEBUG "system APIC only can use physical flat");
- return 1;
- }
-
- if (!strncmp(oem_id, "IBM", 3) && !strncmp(oem_table_id, "EXA", 3)) {
- printk(KERN_DEBUG "IBM Summit detected, will use apic physical");
- return 1;
- }
-#endif
-
- return 0;
-}
-
static int physflat_probe(void)
{
- return apic == &apic_physflat || num_possible_cpus() > 8 || jailhouse_paravirt();
+ return 1;
}
static struct apic apic_physflat __ro_after_init = {
.name = "physical flat",
.probe = physflat_probe,
- .acpi_madt_oem_check = physflat_acpi_madt_oem_check,
.dest_mode_logical = false,
@@ -167,7 +60,4 @@ static struct apic apic_physflat __ro_af
.safe_wait_icr_idle = apic_mem_wait_icr_idle_timeout,
};
-/*
- * We need to check for physflat first, so this order is important.
- */
-apic_drivers(apic_physflat, apic_flat);
+apic_drivers(apic_physflat);
next prev parent reply other threads:[~2024-05-22 22:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 21:21 Early boot regression from f0551af0213 ("x86/topology: Ignore non-present APIC IDs in a present package") Lyude Paul
2024-04-18 8:27 ` Borislav Petkov
2024-04-18 17:20 ` Lyude Paul
2024-04-18 19:13 ` Thomas Gleixner
2024-04-19 5:37 ` Thomas Gleixner
2024-04-19 17:38 ` Lyude Paul
2024-04-19 22:15 ` Thomas Gleixner
2024-04-23 17:09 ` Thomas Gleixner
2024-04-24 20:56 ` Lyude Paul
2024-04-25 2:11 ` Thomas Gleixner
2024-04-25 15:56 ` Lyude Paul
2024-04-25 21:42 ` Thomas Gleixner
2024-05-02 10:33 ` Mario Limonciello
2024-05-08 8:38 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-08 10:30 ` Thomas Gleixner
2024-05-08 21:02 ` Lyude Paul
2024-05-08 23:21 ` Lyude Paul
2024-05-13 14:08 ` Thomas Gleixner
2024-05-13 23:18 ` Lyude Paul
2024-05-13 23:32 ` Lyude Paul
2024-05-14 8:25 ` Thomas Gleixner
2024-05-15 23:15 ` Lyude Paul
2024-05-16 13:38 ` Thomas Gleixner
2024-05-22 19:35 ` Lyude Paul
2024-05-22 22:12 ` Thomas Gleixner [this message]
2024-05-23 5:20 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-23 10:47 ` Thomas Gleixner
2024-05-28 22:43 ` Thomas Gleixner
2024-06-03 16:22 ` Lyude Paul
2024-06-05 23:15 ` Lyude Paul
2024-06-06 9:50 ` Thomas Gleixner
2024-05-09 19:22 ` Lyude Paul
2024-05-08 21:47 ` Thomas Gleixner
2024-05-08 22:09 ` Mario Limonciello
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=874japh4ww.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=mario.limonciello@amd.com \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox