mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yipeng Zou <zouyipeng@huawei.com>
To: <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>,
	<peterz@infradead.org>, <sohil.mehta@intel.com>,
	<rui.zhang@intel.com>, <arnd@arndb.de>, <yuntao.wang@linux.dev>,
	<linux-kernel@vger.kernel.org>
Cc: <zouyipeng@huawei.com>
Subject: [BUG REPORT] x86/apic: CPU Hang in x86 VM During Kdump
Date: Wed, 4 Jun 2025 08:33:19 +0000	[thread overview]
Message-ID: <20250604083319.144500-1-zouyipeng@huawei.com> (raw)

Recently, A issue has been reported that CPU hang in x86 VM.

The CPU halted during Kdump likely due to IPI issues when one CPU was
rebooting and another was in Kdump:

CPU0			  CPU2
========================  ======================
reboot			  Panic
machine shutdown	  Kdump
			  machine shutdown
stop other cpus
			  stop other cpus
...			  ...
local_irq_disable	  local_irq_disable
send_IPIs(REBOOT)	  [critical regions]
[critical regions]	  1) send_IPIs(REBOOT)
			  wait timeout
			  2) send_IPIs(NMI);
Halt,NMI context
			  3) lapic_shutdown [IPI is pending]
			  ...
			  second kernel start
			  4) init_bsp_APIC [IPI is pending]
			  ...
			  local irq enable
			  Halt, IPI context

In simple terms, when the Kdump jump to the second kernel, the IPI that
was pending in the first kernel remains and is responded to by the
second kernel.

I was thinking maybe we need mask IPI in clear_local_APIC() to solve this
problem. In that way, it will clear the pending IPI in both 3) and 4).

I can't seem to find a solution in the SDM manual. I want to ask if this
approach is feasible, or if there are other ways to fix the issue.

Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
---
 arch/x86/kernel/apic/apic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index d73ba5a7b623..68c41d579303 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1117,6 +1117,8 @@ void clear_local_APIC(void)
 	}
 #endif
 
+	// Mask IPI here
+
 	/*
 	 * Clean APIC state for other OSs:
 	 */
-- 
2.34.1


             reply	other threads:[~2025-06-04  8:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-04  8:33 Yipeng Zou [this message]
2025-07-26  9:50 ` Yipeng Zou
2025-07-27 12:39   ` Thomas Gleixner
2025-07-27 20:01 ` Thomas Gleixner
2025-07-29  8:53   ` Thomas Gleixner
2025-07-29 13:35     ` Yipeng Zou
2025-07-29 19:48       ` Thomas Gleixner
2025-08-11 12:51         ` Yipeng Zou

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=20250604083319.144500-1-zouyipeng@huawei.com \
    --to=zouyipeng@huawei.com \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rui.zhang@intel.com \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yuntao.wang@linux.dev \
    /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®