From: Ashok Raj <ashok.raj@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
Mario Limonciello <mario.limonciello@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Tony Battersby" <tonyb@cybernetics.com>,
Ashok Raj <ashok.raj@linux.intel.com>,
Tony Luck <tony.luck@intel.com>,
Arjan van de Veen <arjan@linux.intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Ashok Raj <ashok.raj@intel.com>
Subject: Re: [patch v3 1/7] x86/smp: Make stop_other_cpus() more robust
Date: Thu, 15 Jun 2023 18:58:32 -0700 [thread overview]
Message-ID: <ZIvByEFqiJZOyau2@a4bf019067fa.jf.intel.com> (raw)
In-Reply-To: <20230615193330.263684884@linutronix.de>
Hi Thomas,
On Thu, Jun 15, 2023 at 10:33:50PM +0200, Thomas Gleixner wrote:
> Tony reported intermittent lockups on poweroff. His analysis identified the
> wbinvd() in stop_this_cpu() as the culprit. This was added to ensure that
> on SME enabled machines a kexec() does not leave any stale data in the
> caches when switching from encrypted to non-encrypted mode or vice versa.
>
> That wbindv() is conditional on the SME feature bit which is read directly
> from CPUID. But that readout does not check whether the CPUID leaf is
> available or not. If it's not available the CPU will return the value of
> the highest supported leaf instead. Depending on the content the "SME" bit
> might be set or not.
>
> That's incorrect but harmless. Making the CPUID readout conditional makes
> the observed hangs go away, but it does not fix the underlying problem:
>
> CPU0 CPU1
>
> stop_other_cpus()
> send_IPIs(REBOOT); stop_this_cpu()
> while (num_online_cpus() > 1); set_online(false);
> proceed... -> hang
> wbinvd()
>
> WBINVD is an expensive operation and if multiple CPUs issue it at the same
> time the resulting delays are even larger.
>
> But CPU0 already observed num_online_cpus() going down to 1 and proceeds
> which causes the system to hang.
>
> This issue exists independent of WBINVD, but the delays caused by WBINVD
> make it more prominent.
>
> Make this more robust by adding a cpumask which is initialized to the
> online CPU mask before sending the IPIs and CPUs clear their bit in
> stop_this_cpu() after the WBINVD completed. Check for that cpumask to
> become empty in stop_other_cpus() instead of watching num_online_cpus().
>
> The cpumask cannot plug all holes either, but it's better than a raw
> counter and allows to restrict the NMI fallback IPI to be sent only to
> the CPUs which have not reported within the timeout window.
>
> Fixes: 08f253ec3767 ("x86/cpu: Clear SME feature flag when not in use")
> Reported-by: Tony Battersby <tonyb@cybernetics.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lore.kernel.org/all/3817d810-e0f1-8ef8-0bbd-663b919ca49b@cybernetics.com
> ---
> V3: Use a cpumask to make the NMI case slightly safer - Ashok
> ---
> arch/x86/include/asm/cpu.h | 2 +
> arch/x86/kernel/process.c | 23 +++++++++++++-
> arch/x86/kernel/smp.c | 71 +++++++++++++++++++++++++++++++--------------
> 3 files changed, 73 insertions(+), 23 deletions(-)
I tested them and seems to work fine on my system.
Maybe Tony can check in his setup would be great.
One thought on sending NMI below.
[snip]
>
> /* if the REBOOT_VECTOR didn't work, try with the NMI */
> - if (num_online_cpus() > 1) {
> + if (!cpumask_empty(&cpus_stop_mask)) {
> /*
> * If NMI IPI is enabled, try to register the stop handler
> * and send the IPI. In any case try to wait for the other
> * CPUs to stop.
> */
> if (!smp_no_nmi_ipi && !register_stop_handler()) {
> + u32 dm;
> +
> /* Sync above data before sending IRQ */
> wmb();
>
> pr_emerg("Shutting down cpus with NMI\n");
>
> - apic_send_IPI_allbutself(NMI_VECTOR);
> + dm = apic->dest_mode_logical ? APIC_DEST_LOGICAL : APIC_DEST_PHYSICAL;
> + dm |= APIC_DM_NMI;
> +
> + for_each_cpu(cpu, &cpus_stop_mask) {
> + u32 apicid = apic->cpu_present_to_apicid(cpu);
> +
> + apic_icr_write(dm, apicid);
> + apic_wait_icr_idle();
can we simplify this by just apic->send_IPI(cpu, NMI_VECTOR); ??
next prev parent reply other threads:[~2023-06-16 1:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 20:33 [patch v3 0/7] x86/smp: Cure stop_other_cpus() and kexec() troubles Thomas Gleixner
2023-06-15 20:33 ` [patch v3 1/7] x86/smp: Make stop_other_cpus() more robust Thomas Gleixner
2023-06-16 1:58 ` Ashok Raj [this message]
2023-06-16 7:53 ` Thomas Gleixner
2023-06-16 14:13 ` Ashok Raj
2023-06-16 18:01 ` Thomas Gleixner
2023-06-16 20:57 ` Ashok Raj
2023-06-19 17:51 ` Ashok Raj
2023-06-20 8:09 ` Borislav Petkov
2023-06-16 16:36 ` Tony Battersby
2023-06-15 20:33 ` [patch v3 2/7] x86/smp: Dont access non-existing CPUID leaf Thomas Gleixner
2023-06-19 17:02 ` Limonciello, Mario
2023-06-19 17:15 ` Thomas Gleixner
2023-06-20 8:20 ` Borislav Petkov
2023-06-15 20:33 ` [patch v3 3/7] x86/smp: Remove pointless wmb()s from native_stop_other_cpus() Thomas Gleixner
2023-06-20 8:47 ` Borislav Petkov
2023-06-20 13:00 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-06-15 20:33 ` [patch v3 4/7] x86/smp: Use dedicated cache-line for mwait_play_dead() Thomas Gleixner
2023-06-20 9:01 ` Borislav Petkov
2023-06-20 13:00 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-06-15 20:33 ` [patch v3 5/7] x86/smp: Cure kexec() vs. mwait_play_dead() breakage Thomas Gleixner
2023-06-20 9:23 ` Borislav Petkov
2023-06-20 12:25 ` Thomas Gleixner
2023-06-20 13:00 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-06-15 20:33 ` [patch v3 6/7] x86/smp: Split sending INIT IPI out into a helper function Thomas Gleixner
2023-06-20 9:29 ` Borislav Petkov
2023-06-20 12:30 ` Thomas Gleixner
2023-06-20 13:00 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-06-15 20:34 ` [patch v3 7/7] x86/smp: Put CPUs into INIT on shutdown if possible Thomas Gleixner
2023-06-20 10:27 ` Borislav Petkov
2023-06-20 13:00 ` [tip: x86/core] " tip-bot2 for Thomas Gleixner
2023-07-03 3:44 ` [BUG REPORT] Triggering a panic in an x86 virtual machine does not wait Baokun Li
2023-07-05 8:59 ` Thomas Gleixner
2023-07-06 6:44 ` Baokun Li
2023-07-07 10:18 ` Thomas Gleixner
2023-07-07 12:40 ` Baokun Li
2023-07-07 13:49 ` [tip: x86/core] x86/smp: Don't send INIT to boot CPU tip-bot2 for Thomas Gleixner
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=ZIvByEFqiJZOyau2@a4bf019067fa.jf.intel.com \
--to=ashok.raj@intel.com \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@linux.intel.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=tonyb@cybernetics.com \
--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
Powered by JetHome