From: Ingo Molnar <mingo@kernel.org>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Sandipan Das <sandipan.das@amd.com>,
"H . Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
linux-pm@vger.kernel.org, rafael@kernel.org, pavel@ucw.cz,
linux-perf-users@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH 1/2] x86: Enable x2apic during resume from suspend if used previously
Date: Tue, 24 Oct 2023 10:36:04 +0200 [thread overview]
Message-ID: <ZTeB9K4NYu1sRiZ1@gmail.com> (raw)
In-Reply-To: <20231023160018.164054-2-mario.limonciello@amd.com>
* Mario Limonciello <mario.limonciello@amd.com> wrote:
> If x2apic was enabled during boot with parallel startup
> it will be needed during resume from suspend to ram as well.
>
> Store whether to enable into the smpboot_control global variable
> and during startup re-enable it if necessary.
>
> Cc: stable@vger.kernel.org # 6.5+
> Fixes: 0c7ffa32dbd6 ("x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it")
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> arch/x86/include/asm/smp.h | 1 +
> arch/x86/kernel/acpi/sleep.c | 12 ++++++++----
> arch/x86/kernel/head_64.S | 15 +++++++++++++++
> 3 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
> index c31c633419fe..86584ffaebc3 100644
> --- a/arch/x86/include/asm/smp.h
> +++ b/arch/x86/include/asm/smp.h
> @@ -190,6 +190,7 @@ extern unsigned long apic_mmio_base;
> #endif /* !__ASSEMBLY__ */
>
> /* Control bits for startup_64 */
> +#define STARTUP_ENABLE_X2APIC 0x40000000
> #define STARTUP_READ_APICID 0x80000000
>
> /* Top 8 bits are reserved for control */
> diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
> index 6dfecb27b846..29734a1299f6 100644
> --- a/arch/x86/kernel/acpi/sleep.c
> +++ b/arch/x86/kernel/acpi/sleep.c
> @@ -11,6 +11,7 @@
> #include <linux/dmi.h>
> #include <linux/cpumask.h>
> #include <linux/pgtable.h>
> +#include <asm/apic.h>
> #include <asm/segment.h>
> #include <asm/desc.h>
> #include <asm/cacheflush.h>
> @@ -129,11 +130,14 @@ int x86_acpi_suspend_lowlevel(void)
> */
> current->thread.sp = (unsigned long)temp_stack + sizeof(temp_stack);
> /*
> - * Ensure the CPU knows which one it is when it comes back, if
> - * it isn't in parallel mode and expected to work that out for
> - * itself.
> + * Ensure x2apic is re-enabled if necessary and the CPU knows which
> + * one it is when it comes back, if it isn't in parallel mode and
> + * expected to work that out for itself.
> */
> - if (!(smpboot_control & STARTUP_PARALLEL_MASK))
> + if (smpboot_control & STARTUP_PARALLEL_MASK) {
> + if (x2apic_enabled())
> + smpboot_control |= STARTUP_ENABLE_X2APIC;
> + } else
> smpboot_control = smp_processor_id();
Yeah, so instead of adding further kludges to the 'parallel bringup is
possible' code path, which is arguably a functional feature that shouldn't
have hardware-management coupled to it, would it be possible to fix
parallel bringup to AMD-SEV systems, so that this code path isn't a
quirk-dependent "parallel boot" codepath, but simply the "x86 SMP boot
codepath", where all SMP x86 systems do a parallel bootup?
The original commit by Thomas says:
0c7ffa32dbd6 ("x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it")
| Unfortunately there is no RDMSR GHCB protocol at the moment, so enabling
| AMD-SEV guests for parallel startup needs some more thought.
But that was half a year ago, isn't there RDMSR GHCB access code available now?
This code would all read a lot more natural if it was the regular x86 SMP
bootup path - which it is 'almost' today already, modulo quirk.
Obviously coupling functional features with hardware quirks is fragile, for
example your patch extending x86 SMP parallel bringup doesn't extend the
AMD-SEV case, which may or may not matter in practice.
So, if it's possible, it would be nice to fix AMD-SEV systems as well and
remove this artificial coupling.
Also, side note #1: curly braces should be balanced.
> #endif
> initial_code = (unsigned long)wakeup_long64;
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index ea6995920b7a..fcfa79105928 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -236,10 +236,15 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
> * used to look up the CPU number. For booting a single CPU, the
> * CPU number is encoded in smpboot_control.
> *
> + * Bit 30 STARTUP_ENABLE_X2APIC (Enable X2APIC mode)
> * Bit 31 STARTUP_READ_APICID (Read APICID from APIC)
> * Bit 0-23 CPU# if STARTUP_xx flags are not set
Side note #2: you mixed up the comment ordering here.
Thanks,
Ingo
next prev parent reply other threads:[~2023-10-24 8:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 16:00 [PATCH 0/2] Fixes for s3 with parallel bootup Mario Limonciello
2023-10-23 16:00 ` [PATCH 1/2] x86: Enable x2apic during resume from suspend if used previously Mario Limonciello
2023-10-24 8:36 ` Ingo Molnar [this message]
2023-10-24 15:36 ` Mario Limonciello
2023-10-24 17:01 ` Ingo Molnar
2023-10-25 19:04 ` Mario Limonciello
2023-10-24 17:30 ` Tom Lendacky
2023-10-23 16:00 ` [PATCH 2/2] perf/x86/amd: Don't allow pre-emption in amd_pmu_lbr_reset() Mario Limonciello
2023-10-24 8:02 ` Ingo Molnar
2023-10-24 15:32 ` Mario Limonciello
2023-10-24 15:59 ` Peter Zijlstra
2023-10-24 16:04 ` Mario Limonciello
2023-10-24 16:30 ` Peter Zijlstra
2023-10-24 16:34 ` Peter Zijlstra
2023-10-25 11:47 ` Sandipan Das
2023-10-24 16:51 ` Ingo Molnar
2023-10-24 18:30 ` Mario Limonciello
2023-10-24 22:24 ` Peter Zijlstra
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=ZTeB9K4NYu1sRiZ1@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=sandipan.das@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox