From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger@xenproject.org>,
"Teddy Astie" <teddy.astie@vates.tech>
Subject: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated panic()
Date: Tue, 18 Aug 2026 14:07:38 +0100 [thread overview]
Message-ID: <20260818130738.1911850-1-andrew.cooper3@citrix.com> (raw)
Panicing in the case of a timeout turns out to be about the worst possible
action Xen can take. It leaves all other APs waiting on the condition
variable, some in NMI context. As a result, they fail to be shot down and
dump state for kexec crash analysis.
Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
excess of the of the arbitrary 1s Xen allows. This time is spent in the WRMSR
to load the blob, and there's nothing the system can do but to sit and wait.
Despite the delay, the system as a whole does survive.
Microcode loading occures through admin operation only, so get rid of the
timeout completely. It does nothing but make a bad sitaution worse.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
xen/arch/x86/cpu/microcode/core.c | 18 +-----------------
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 9b8d1e09cb98..12edd52fee87 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -52,12 +52,6 @@
*/
#define MICROCODE_CALLIN_TIMEOUT_US 30000
-/*
- * Timeout for each thread to complete update is set to 1s. It is a
- * conservative choice considering all possible interference.
- */
-#define MICROCODE_UPDATE_TIMEOUT_US 1000000
-
static bool __initdata __maybe_unused ucode_mod_forced;
static unsigned int nr_cores;
@@ -422,17 +416,7 @@ static int control_thread_fn(const struct microcode_patch *patch,
/* Wait for primary threads finishing update */
while ( (done = atomic_read(&cpu_out)) != nr_cores )
{
- /*
- * During each timeout interval, at least a CPU is expected to
- * finish its update. Otherwise, something goes wrong.
- *
- * Note that RDTSC (in wait_for_condition()) is safe for threads to
- * execute while waiting for completion of loading an update.
- */
- if ( wait_for_condition(wait_cpu_callout, (done + 1),
- MICROCODE_UPDATE_TIMEOUT_US) )
- panic("Timeout when finished updating microcode (finished %u/%u)\n",
- done, nr_cores);
+ cpu_relax();
/* Print warning message once if long time is spent here */
if ( tick && rdtsc_ordered() - tick >= cpu_khz * 1000 )
--
2.39.5
next reply other threads:[~2026-08-18 13:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 13:07 Andrew Cooper [this message]
2026-08-18 14:31 ` [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated panic() Jan Beulich
2026-08-19 11:13 ` Andrew Cooper
2026-08-19 11:56 ` Jan Beulich
2026-08-19 14:04 ` Andrew Cooper
2026-08-19 14:53 ` Jan Beulich
2026-08-19 21:06 ` Andrew Cooper
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=20260818130738.1911850-1-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger@xenproject.org \
--cc=teddy.astie@vates.tech \
--cc=xen-devel@lists.xenproject.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.